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APPARATUS AND METHOD FOR CONTROLLING 
ACCESS TO A MEMORY 



01 TO mAT** 



The present invention relates to an apparatus and method for controlling access 
5 to a memory. 

A data processing apparatus will typically include a processor for running 
applications loaded onto the data processing apparatus. The processor will operate 
under the control of an operating system. The data required to run any particular 
application will typically be stored within a memory of the data processing apparatus. It 
10 will be appreciated that the data may consist of the instructions contained within the 
application and/or the actual data values used during the execution of those instructions 
on the processor. 

There arise many instances where the data used by at least one of the 
applications is sensitive data that should not be accessible by other applications that can 

15 be run on the processor. An example would be where the data processing apparatus is a 
smart card, and one of the applications is a security application which uses sensitive 
data, such as for example secure keys, to perform validation, authentication, decryption 
and the like. It is clearly important in such situations to ensure that such sensitive data is 
kept secure so that it cannot be accessed by other applications that may be loaded onto 

20 the data processing apparatus, for example hacking applications that have been loaded 
onto the data processing apparatus with the purpose of seeking to access that secure 
data. 

In known systems, it has typically been the job of the operating system developer 
to ensure that the operating system provides sufficient security to ensure that the secure 
25 data of one application cannot be accessed by other applications running under the 
control of the operating system. However, as systems become more complex, the 
general trend is for operating systems to become larger and more complex, and in such 
situations it becomes increasingly difficult to ensure sufficient security within the 
operating system itself. 

30 Examples of systems seeking to provide secure storage of sensitive data and to 

provide protection against malicious program code are those described in United States 
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Patent Application US 2002/0007456 Al and United States Patents US 6,282,657 B and 
US 6,292,874 B. 

Accordingly, it will be desirable to provide an improved technique for seeking to 
retain the security of such secure data contained within the memory of the data 
5 processing apparatus. 

Viewed from a first aspect, the present invention provides a data processing 
apparatus, comprising: a processor operable in a plurality of modes and either a secure 
domain or a non-secure domain, including at least one non-secure mode being a mode 
in the non-secure domain and at least one secure mode being a mode in the secure 
10 domain, in said at least one non-secure mode the processor being operable under the 
control of a non-secure operating system and in said at least one secure mode the 
processor being operable under the control of a secure operating system; a memory 
operable to store data required by the processor and comprising secure memory for 
storing secure data and non-secure memory for storing non-secure data, the processor 
15 being operable to issue a memory access request when access to an item of data in the 
memory is required; a memory management unit operable, upon receipt of the memory 
access request from the processor, to perform one or more predetermined access control 
functions to control issuance of the memory access request to the memory; and partition 
checking logic managed by the secure operating system, and operable whenever the 
20 memory access request is issued by the processor when operating in said at least one 
non-secure mode to detect if the memory access request is seeking to access the secure 
memory, and upon such detection to prevent the access specified by that memory access 
request. 

In accordance with the present invention, the data processing apparatus is 
25 arranged to have both a secure domain and a non-secure domain. The processor is then 
operable in a plurality of modes including at least one non-secure mode which is a mode 
in the non-secure domain, and at least one secure mode which is a mode in the secure 
domain. When in a non-secure mode of operation, the processor is operable under the 
control of a non-secure operating system, for example a standard pre-existing operating 
30 system. However, when in a secure mode of operation, the processor is operable under 
the control of a secure operating system. The secure operating system is preferably 
relatively small compared with the non-secure operating system, and hence takes the 
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form of a secure kernel for use when executing certain secure functions. By this 
approach, the secure domain can be seen as providing a secure world to enable certain 
sensitive operations to be carried out in a controlled environment. Other applications 
would then remain in the non-secure domain, which can be considered as a non-secure 
5 world. 

Furthermore, in accordance with the present invention, the memory comprises 
secure memory for storing secure data and non-secure memory for storing non-secure 
data. A memory management unit is provided which is operable, upon receipt of a 
memory access request issued by the processor when the processor wishes to access an 
10 item of data in the memory, to perform one or more predetermined access control 
functions to control issuance of that memory access request to the memory. As an 
example, such predetermined access control functions could involve translation of 
virtual addresses to physical addresses, review of access permissions rights to ensure 
that the processor in its current mode of operation is entitled to access the data item 
15 requested, analysis of region attributes, for example to determine whether the data item 
is cacheable, bufferable, etc, as will be appreciated by those skilled in the art. 

Further, in accordance with the present invention, in order to ensure the security 
of secure data in the secure memory, partition checking logic is also provided which is 
managed by the secure operating system, and is operable whenever the memory access 
20 request is issued by the processor when it is operating in a non-secure mode, to detect if 
the memory access request is seeking to access the secure memory. Upon such a 
detection, the partition checking logic then prevents the access specified by that memory 
access request from occurring. Since the partition checking logic is managed by the 
secure operating system, the set-up of the partition checking logic cannot be altered by 
25 non-secure applications, thus preventing unauthorised access to the secure data. 

The partition checking logic will have access to information about the partitions 
between the secure memory and the non-secure memory. It will be appreciated that this 
partitioning information could be hardwired in embodiments where the physical 
partition between secure memory and non-secure memory cannot be altered. However, 
30 in preferred embodiments, the partitioning between secure memory and non-secure 
memory is configurable by the processor when the processor is operating in a 
predetermined secure mode, and in such embodiments, the partition checking logic is 
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managed by the processor when operating in that predetermined secure mode. Hence, if 
a rogue application were installed onto the processor with the aim of seeking to access 
secure data, that application will not be able to be run in the secure domain, and 
accordingly it cannot alter the partitioning information. Hence, even if that application 
can output a memory access request which is seeking to access a location within the 
secure memory, the partition checking logic will detect that that application executing in 
a non-secure mode of the processor is seeking to access a secure memory location, and 
will prevent the access taking place. 

It will be appreciated by those skilled in the art that memory access requests may 
specify virtual addresses, or in certain embodiments may specify physical addresses, 
depending on the architecture of the data processing system. However, in preferred 
embodiments, when the processor is operating in a non-secure mode, memory access 
requests will specify a virtual address, and the memory management unit is controlled 
by the non-secure operating system. In such embodiments, one of the preferred access 
control functions performed by the memory management unit comprises conversion of 
the virtual address to a physical address, the partition checking logic being operable to 
prevent the access specified by that memory access request if the physical address to be 
generated by the memory management unit is within the secure memory. 

Further, in preferred embodiments, when the processor is operating in a secure 
mode, the memory access request may specify a virtual address, in which event the 
memory management unit is controlled by the secure operating system and one of said 
predetermined access control functions performed by the memory management unit 
comprises conversion of the virtual address to a physical address, the partition checking 
logic not being used in the at least one secure mode. 

In one embodiment, all modes of operation of the processor employ virtual 
addresses for memory access requests, and the partition checking logic is provided 
within the memory management unit, and is operable whenever the processor is 
operating in a non-secure mode. Hence, irrespective of the mode of operation, the 
memory management unit is employed to perform the necessary address translation, and 
any other required access control functions, but the partition checking logic is preferably 
only used when the processor is operating in a non-secure mode, since typically when 
the processor is operating in a secure mode, there will be no restrictions on its access to 
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the data in the memory. However, it will be appreciated that in alternative 
embodiments, some degree of partition checking may be provided for certain secure 
modes of operation. 

In an alternative embodiment of the present invention, there is at least one 
particular secure mode of operation in which the memory access request is specified 
directly by a physical address, and hence in such a particular secure mode, there is no 
requirement for any virtual to physical address translation to be performed. Whilst the 
approach of specifying physical addresses directly is less flexible than the virtual address 
approach, it is inherently more secure since there is no mapping between virtual 
addresses and physical addresses to be performed. Hence, in one particularly preferred 
embodiment, the secure mode that directly specifies physical addresses for memory 
access requests is the most secure mode of operation, in preferred embodiments this 
mode being referred to as a monitor mode of operation, and being responsible for 
managing the transition of the data processing apparatus between the non-secure and the 
secure domains. 

In such preferred embodiments, the data processing apparatus further comprises 
a memory protection unit within which the partition checking logic is provided, the 
memory protection unit being managed by the secure operating system, wherein when 
the processor is operating in a particular secure mode, the memory access request 
specifies a physical address for a memory location, the memory management unit is not 
used, and the memory protection unit is operable to perform at least memory access 
permission processing to verify whether the memory location specified by the physical 
address is accessible in said particular secure mode. Hence, when the processor is 
operating in a particular secure mode, the access is managed solely by a memory 
protection unit managed by the secure operating system. 

In preferred embodiments, the memory includes at least one table containing for 
each of a number of memory regions an associated descriptor, the memory management 
unit comprising an internal storage unit for storing access control information derived 
from the descriptors and used by the memory management unit to perform the 
predetermined access control functions for the memory access request, the partition 
checking logic being operable, when the processor is operating in said at least one non- 
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secure mode, to prevent the internal storage unit from storing access control information 
that would allow access to said secure memory. 

As will be appreciated by those skilled in the art, such tables of descriptors can 
take a variety of forms, but in preferred embodiments such tables are page tables 
5 defining for each of a number of pages of memory a corresponding descriptor within 
which is described access control information relevant to that page of memory. Hence, 
the descriptor may for example define a virtual address portion and a corresponding 
physical address portion for the page, access permission information, such as whether 
that page is accessible in supervisor mode, user mode, etc, and region attributes such as 
10 whether the data contained within that page is cacheable, bufferable, etc. 

In embodiments where the memory access request specifies a virtual address, 
and hence the descriptors in the table contain at least a virtual address portion and a 
corresponding physical address portion for the corresponding memory region, the 
partition checking logic is operable, when the processor is operating in said at least one 
15 non-secure mode, to prevent the internal storage unit from storing as access control 
information the physical address portion if the physical address that would then be 
produced for the virtual address is within the secure memory. 

As will be appreciated, in a correctly running system, a non-secure application 
being run by the processor in a non-secure mode will typically not be aware of the 
20 secure memory, and the table referenced by the processor to convert virtual addresses to 
physical addresses when the processor is operating in such a non-secure mode should 
not reference memory regions that incorporate any part of the secure memory. 
However, in instances where the non-secure application is a hacking application 
designed solely to seek access to the secure information, it will be appreciated that it 
25 might be possible to corrupt the descriptors in the table referenced by the processor 
when in a non-secure mode, to produce a mapping which would point to parts of the 
secure memory. However, since the partition checking logic is managed in the secure 
domain by a secure operating system, it will not be corrupted by such activities, and 
accordingly can detect such situations where the physical address portion retrieved from 
30 a descriptor is such that the physical address that would then be produced for a particular 
virtual address is within the secure memory. Accordingly, if the table in memory has 
been fraudulently altered, the partition checking logic will prevent the internal storage 
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unit of the memory management unit from storing the altered access control information 
if an access to secure memory would result, and hence will prevent the access from 
taking place. 

The internal storage unit within the memory management unit may take a variety 
of forms. However, in preferred embodiments the internal storage unit is a translation 
lookaside buffer (TLB) operable to store for a number of virtual address portions the 
corresponding physical address portions obtained from corresponding descriptors 
retrieved from the at least one table. 

In one embodiment, a single TLB will be contained within the memory 
management unit, and the partition checking logic will be operable to ensure that any 
descriptor retrieved from a table in memory will not be stored within the TLB if the 
processor is operating in non-secure mode and the physical address that would be 
produced based on the access control information within that descriptor would point to a 
location in secure memory. When switching between secure and non-secure modes of 
operation, the TLB would be flushed to ensure that descriptors relevant to secure mode 
are not available in non-secure mode, and vice versa. 

However, in an alternative embodiment, the internal storage unit consists of both 
a micro-TLB and main TLB, the main TLB being used to store descriptors retrieved by 
the memory management unit from the at least one table in memory, and access control 
information being transferred from the main TLB to the micro-TLB prior to use of that 
access control information by the memory management unit to perform the 
predetermined access control functions for the memory access request. In such 
embodiments, the partition checking logic is operable, when the processor is operating 
in said at least one non-secure mode, to prevent the transfer of any access control 
information from the main TLB to the micro-TLB that would allow access to said secure 
memory. 

Hence, in such embodiments, descriptors can be copied into the main TLB, but 
the partition checking logic is operable to police the interface between the main TLB 
and the micro-TLB when the processor is operating in non-secure mode, to ensure that 
no access control information is passed to the micro-TLB that would allow access to the 
secure memory. 
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In preferred embodiments, more than one table in memory is provided, and 
different tables are used dependent on the mode of operation, this thereby allowing 
different access control information to be defined for different modes of operation. 
More particularly, in preferred embodiments, the at least one table comprises a non- 
5 secure table for use when the processor is operating in said at least one non-secure mode 
and containing descriptors generated by the non-secure operating system, in the event 
that a descriptor within that non-secure table is associated with a memory region that at 
least partially incorporates a part of the secure memory, the partition checking logic 
being operable, when the processor is operating in non-secure mode, to prevent the 
10 internal storage unit from storing as access control information the physical address 
portion specified by that descriptor if the physical address that would then be produced 
for the virtual address is within the secure memory. 

Additionally, in such preferred embodiments where virtual to physical address 
translation occurs in at least one secure mode, the at least one table further comprises a 
15 secure table within the secure memory that contains descriptors generated by the secure 
operating system, the main TLB having a flag associated with each descriptor stored 
within the main TLB to identify whether that descriptor is from said non-secure table or 
said secure table. 

By incorporating a flag within the main TLB to indicate whether a 
20 corresponding descriptor is from the non-secure table or the secure table, there is no 
need to flush the main TLB when the operation of the processor moves between the 
secure domain and the non-secure domain, or vice versa. When access control 
information is to be passed to the micro-TLB from a descriptor in the main TLB, only 
those descriptors that are appropriate given the current domain in which the processor is 
25 operating will be considered. Accordingly, if the processor is operating in a non-secure 
mode, and hence is in the non- secure domain, then only those descriptors in the main 
TLB whose associated flag indicates are from the non-secure table will be reviewed as 
candidate descriptors from which to obtain the access control information to be passed 
to the micro-TLB. 

30 In such preferred embodiments, the micro-TLB is preferably flushed whenever 

the mode of operation of the processor changes between a secure mode and a non-secure 
mode, in the secure mode access control information only being transferred to the 
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micro-TLB from a descriptor in the main TLB that said associated flag indicates is from 
the secure table, and in the non-secure mode access control information only being 
transferred to the micro-TLB from a descriptor in the main TLB that said associated flag 
indicates is from the non-secure table. The micro-TLB is generally significantly smaller 
than the main TLB, and hence the flushing of the micro-TLB whenever the processor 
moves between the secure domain and the non-secure domain does not have a 
significant impact on performance. Since the predetermined access control functions 
performed by the memory management unit are only performed having regard to access 
control information in the micro-TLB, the above described mechanism ensures that for 
any particular mode of operation of the processor, the micro-TLB will only contain 
access control information derived from descriptors obtained from the appropriate 
memory table, i.e. from a non-secure table when the processor is operating in a non- 
secure mode, or a from a secure table when the processor is operating in a secure mode. 

In embodiments where all secure modes of operation specify physical addresses 
directly within their memory access requests, it will be appreciated that there will not be 
a need for such a flag within the main TLB, as the main TLB will only store non-secure 
descriptors. 

It will be appreciated that in certain implementations, the memory will not only 
be accessible by the processor, but may also be accessible by other devices. For 
example, in one embodiment, the memory is coupled to a device bus via which a device 
other than the processor may seek access to the memory. In such embodiments, secure 
data in the memory needs to be protected not only from rogue applications executed by 
the processor, but also from any hacking activities initiated via other devices coupled to 
the device bus. Accordingly, in such embodiments, the data processing apparatus 
preferably further comprises additional partition checking logic coupled to the device 
bus and operable when said device issues a memory access request to said secure 
memory to only allow access to said secure memory if that device is authorised to access 
said secure memory. 

In preferred embodiments, the additional partition checking logic has regard to a 
current mode of operation of the device, and hence for example will only allow the 
device to have access to a secure part of the memory if that device can verify that it is 
operating in a secure mode. More particularly, in preferred embodiments, the memory 



PO 15379GB 10 

access request issued by the device includes a domain signal identifying whether the 
device is operating in said at least one secure mode or said at least one non-secure mode. 
This domain signal is preferably asserted at the hardware level and hence is only 
assertable by an application which the device itself has verified is able to be run in the 
secure domain. More particularly, in preferred embodiments, the device has a 
predetermined pin for outputting the domain signal onto the device bus, and by default 
the domain signal is set to indicate that the device is operating in a non-secure mode. 
Hence, only when the device is executing secure applications in the secure domain will 
the domain signal be set to indicate that the device is operating in the secure domain, 
and only when that domain signal is set will the additional partition checking logic allow 
access to secure data in the memory. 

It will be appreciated that the memory can take a variety of forms, and can be 
located in a variety of places within the data processing apparatus. For example, the 
memory may consist of one or more of a variety of elements, for example Random 
Access Memory (RAM), Read Only Memory (ROM), a hard disk drive, a Tightly 
Coupled Memory (TCM), one or more caches, a variety of registers provided within 
peripheral devices, etc, and the address range of the memory will be such as to allow 
these various elements of the memory to be separately addressed. Accordingly, whilst in 
some embodiments at least part of the memory may be coupled to a device bus as 
described above, other parts of the memory may be coupled to a different bus. 

For example, in one embodiment, the processor is coupled to a system bus, and a 
part of the memory comprises a tightly coupled memory (TCM) connected to the system 
bus. As will be appreciated by those skilled in the art, such a TCM is often used to store 
data used frequently by the processor, since access to the TCM via the system bus is 
significantly faster than access to external memory, for example memory on the device 
bus. Often, the physical address range for the TCM is definable within a control register 
of the data processing apparatus. However, this can give rise to certain security issues, 
as can be illustrated by the following example. 

When the processor is operating in a non-secure mode, the non-secure operating 
system may be allowed to program that control register in order to define as the TCM 
memory a physical address space which overlaps with part of the secure memory. When 
the processor subsequently operates in the secure domain, the secure operating system 
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may cause secure data to be stored in this secure memory part, in which event that 
secure data will typically be stored in the TCM rather than the external memory, since 
the TCM will typically have a higher priority. However, if the non-secure operating 
system subsequently changed again the setting of the physical address range for the 
5 TCM so that the previous secure memory part is now mapped in a non-secure physical 
area of memory, it will be appreciated that the non-secure operating system can then 
access the secure data, since the partition checking logic will see the area as non- 
secure and won't assert an abort. Hence, to summarise, if the TCM is configured to 
act as normal local RAM and not as SmartCache, it may be possible for the non- 
10 secure operating system to read secure world data if it can move the TCM base 
register to non-secure physical address. 

In order to avoid this scenario, the data processing apparatus of preferred 
embodiments is preferably provided with a control flag which is settable by the 
processor when operating in a privileged secure mode to indicate whether the tightly 
15 coupled memory is controllable by the processor only when executing in a privileged 
secure mode or is controllable by the processor when executing in the at least one non- 
secure mode. The control flag is set by the secure operating system, and in effect 
defines whether the TCM is controlled by the secure privileged modes or by non-secure 
modes. Hence, one configuration that can be defined is that the TCM is only controlled 
20 when the processor is operating in a privileged secure mode of operation. In such 
embodiments, any non-secure access attempted to the TCM control registers will 
cause an undefined instruction exception to be entered. 

In an alternative configuration, the TCM can be controlled by the processor 
when operating in a non-secure mode of operation. In such embodiments, the TCM is 
25 only used by the non-secure applications. No secure data can be stored to or loaded 
from the TCM. Hence, when a secure access is performed, no look-up is performed 
within the TCM to see if the address matched the TCM address range. In one 
preferred embodiment, the TCM is configured so that it is only used by the non-secure 
operating system, this having the benefit that the non-secure operating system does not 
30 need to be changed, since operation proceeds in the normal manner with the TCM 
available to the non-secure operating system. 
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Viewed from a second aspect, the present invention provides a method of 
controlling access to a memory in a data processing apparatus, the data processing 
apparatus comprising a processor operable in a plurality of modes and either a secure 
domain or a non-secure domain, including at least one non-secure mode being a mode in 
the non-secure domain and at least one secure mode being a mode in the secure domain, 
in said at least one non-secure mode the processor being operable under the control of 
a non-secure operating system and in said at least one secure mode the processor 
being operable under the control of a secure operating system, the memory being 
operable to store data required by the processor and comprising secure memory for 
storing secure data and non-secure memory for storing non-secure data, the method 
comprising the steps of: (i) issuing from the processor a memory access request when 
access to an item of data in the memory is required; (ii) performing one or more 
predetermined access control functions to control issuance of the memory access request 
to the memory; (iii) whenever the memory access request is issued by the processor 
when operating in said at least one non-secure mode, employing partition checking logic 
managed by the secure operating system to detect if the memory access request is 
seeking to access the secure memory; and (iv) upon such detection, preventing the 
access specified by that memory access request. 

The present invention will be described further, by way of example only, with 
reference to preferred embodiments thereof as illustrated in the accompanying 
drawings, in which: 

Figure 1 is a block diagram schematically illustrating a data processing 
apparatus in accordance with preferred embodiments of the present invention; 

Figure 2 schematically illustrates different programs operating in a non-secure 
domain and a secure domain; 

Figure 3 schematically illustrates a matrix of processing modes associated with 
different security domains; 



r . 
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Figures 4 and 5 schematically illustrate different relationships between 
processing modes and security domains; 



Figure 6 illustrates one programmer's model of a register bank of a processor 
5 depending upon the processing mode; 

Figure 7 illustrates an example of providing separate register banks for a 
secure domain and a non-secure domain; 

3 Figure 8 schematically illustrates a plurality of processing modes with 

switches between security domains being made via a separate monitor mode; 



Figure 9 schematically illustrates a scenario for security domain switching 
using a mode switching software interrupt instruction; 

15 

Figure 10 schematically illustrates one example of how non-secure interrupt 
requests and secure interrupt requests may be processed by the system; 

Figures 1 1 A and 1 IB schematically illustrate an example of non-secure 
20 interrupt request processing and an example of secure interrupt request processing in 
accordance with Figure 10; 



Figure 12 illustrates an alternative scheme for the handling of non-secure 
interrupt request signals and secure interrupt request signals compared to that 
25 illustrated in Figure 1 0; 



Figures 13A and 13B illustrate example scenarios for dealing with a non- 
secure interrupt request and a secure interrupt request in accordance with the scheme 
illustrated in Figure 12; 

30 

Figure 14 is an example of a vector interrupt table; 
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Figure 15 schematically illustrates multiple vector interrupt tables associated 

with different security domains; 



10 



Figure 16 schematically illustrates an exception control register; 

Figure 17 is a flow diagram illustrating how an instruction attempting to 
change a processing status register in a manner that alters the security domain setting 
can generate a separate mode change exception which in turn triggers entry into the 
monitor mode and running of the monitor program; 

Figures 18 to 20 illustrate a view of different processing modes and scenario 
for switching between secure and non-secure domains in accordance with another 
example embodiment(s); 

15 Figure 21 is a diagram illustrating the memory management logic used in one 

embodiment of the present invention to control access to memory; 

Figure 22 is a block diagram illustrating the memory management logic of a 
second embodiment of the present invention used to control access to memory; 

20 

Figure 23 is a flow diagram illustrating the process performed in one 
embodiment of the present invention within the memory management logic to process 
a memory access request that specifies a virtual address; 

25 Figure 24 is a flow diagram illustrating the process performed in one 

embodiment of the present invention within the memory management logic to process 
a memory access request that specifies a physical address; 

Figure 25 schematically illustrates how the partition checker of preferred 
30 embodiments is operable to prevent access to a physical address within secure 
memory when the device issuing the memory access request is operating in a non- 
secure mode; 
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Figure 26 is a diagram illustrating the use of both a non-secure page table and 
a secure page table in preferred embodiments of the present invention; 

Figure 27 is a diagram illustrating two forms of flag used within the main 
translation lookaside buffer (TLB) of preferred embodiments; 

Figure 28 illustrates how memory may be partitioned after a boot stage in one 
embodiment of the present invention; 

Figure 29 illustrates the mapping of the non-secure memory by the memory 
management unit following the performance of the boot partition in accordance with 
an embodiment of the present invention; 

Figure 30 illustrates how the rights of a part of memory can be altered to allow 
a secure application to share memory with a non-secure application in accordance 
with an embodiment of the present invention; 

Figure 3 1 illustrates how devices may be connected to the external bus of the 
data processing apparatus in accordance with one embodiment of the present 
invention; 

Figure 32 is a block diagram illustrating how devices may be coupled to the 
external bus in accordance with the second embodiment of the present invention; 

Figure 33 schematically shows possible granularity of monitoring functions for 
different modes and applications running on a processor; 

Figure 34 shows possible ways of initiating different monitoring functions; 

Figure 35 shows a table of control values for controlling availability of 
different monitoring functions; 
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Figure 36 shows a positive-edge triggered FLIP-FLOP view; 
Figure 37 a scan chain cell; 

5 

Figure 38 shows a plurality of scan chain cells in a scan chain; 
Figure 39 shows a debug TAP controller; 
1 0 Figure 40 A shows a debug TAP controller with a JADI input; 

Figure 40B shows a scan chain cell with a bypass register; 

Figure 41 schematically illustrates a processor comprising a core, scan chains 
15 and a Debug Status and Control Register; 

Figure 42 schematically illustrates the factors controlling debug or trace 
initialisation; 

20 Figures 43 A and 43 B show a summary of debug granularity; 

Figure 44 schematically illustrates the granularity of debug while it is running; 

Figure 45A and 45B show monitor debug when debug is enabled in secure 
25 world and when it is not enabled respectively. 

Figure 1 is a block diagram illustrating a data processing apparatus in 
accordance with preferred embodiments of the present invention. The data processing 
apparatus incorporates a processor core 10 within which is provided an arithmetic 

30 logic unit (ALU) 16 arranged to execute sequences of instructions. Data required by 
the ALU 16 is stored within a register bank 14. The core 10 is provided with various 
monitoring functions to enable diagnostic data to be captured indicative of the 
activities of the processor core. As an example, an Embedded Trace Module (ETM) 
22 is provided for producing a real time trace of certain activities of the processor core 

35 in dependence on the contents of certain control registers 26 within the ETM 22 
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defining which activities are to be traced. The trace signals are typically output to a 
trace buffer from where they can subsequently be analysed. A vectored interrupt 
controller 2 1 is provided for managing the servicing of a plurality of interrupts which 
may be raised by various peripherals Q. 

Further, as shown in Figure 1, another monitoring functionality that can be 
provided within the core 10 is a debug function, a debugging application external to 
the data processing apparatus being able to communicate with the core 1 0 via a Joint 
Test Access Group (JTAG) controller 1 8 which is coupled to one or more scan chains 
12. Information about the status of various parts of the processor core 10 can be 
output via the scan chains 1 2 and the JTAG controller 1 8 to the external debugging 
application. An In Circuit Emulator (ICE) 20 is used to store within registers 24 
conditions identifying when the debug functions should be started and stopped, and 
hence for example will be used to store breakpoints, watchpoints, etc. 

The core 10 is coupled to a system bus 40 via memory management logic 30 
which is arranged to manage memory access requests issued by the core 10 for access 
to locations in memory of the data processing apparatus. Certain parts of the memory 
may be embodied by memory units connected directly to the system bus 40, for 
example the Tightly Coupled Memory (TCM) 36, and the cache 38 illustrated in 
Figure 1 . Additional devices may also be provided for accessing such memory, for 
example a Direct Memory Access (DMA) controller 32. Typically, various control 
registers 34 will be provided for defining certain control parameters of the various 
elements of the chip, these control registers also being referred to herein as 
coprocessor 15 (CP 15) registers. 

The chip containing the core 1 0 will typically be coupled to an external bus 70 
(for example a bus operating in accordance with the "Advanced Microcontroller Bus 
Architecture" (AMBA) specification developed by ARM Limited) via an external bus 
interface 42, and various devices may be connected to the external bus 70. These 
devices may include master devices such as a digital signal processor (DSP) 50, or a 
direct memory access (DMA) controller 52, as well as various slave devices such as 
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the boot ROM 44, the screen driver 46, the external memory 56, an input/output (I/O) 
interface 60 or a key storage unit 64. These various slave devices illustrated in Figure 
1 can all be considered as incorporating parts of the overall memory of the data 
processing apparatus. For example, the boot ROM 44 will form part of the 
5 addressable memory of the data processing apparatus, as will the external memory 56. 
Further, devices such as the screen driver 46, I/O interface 60 and key storage unit 64 
will all include internal storage elements such as registers or buffers 48, 62, 66, 
respectively, which are all independently addressable as part of the overall memory of 
the data processing apparatus. As will be discussed in more detail later, a part of the 
10 memory, e.g. part of external memory 56, will be used to store one or more page 
tables 58 defining information relevant to control of memory accesses. 

As will be appreciated by those skilled in the art, the external bus 70 will 
typically be provided with arbiter and decoder logic 54, the arbiter being used to 
15 arbitrate between multiple memory access requests issued by multiple master devices, 
for example the core 10, the DMA 32, the DSP 50, the DMA 52, etc, whilst the 
decoder will be used to determine which slave device on the external bus should 
handle any particular memory access request. 

20 Figure 2 schematically illustrates various programs running on a processing 

system having a secure domain and a non-secure domain. The system is provided 
with a monitor program 72 which executes at least partially in a monitor mode. A 
security status flag is accessible only within the monitor mode and may be written by 
the monitor program 72. The monitor program 72 is responsible for managing all 

25 changes between the secure domain and the non-secure domain in either direction. 
From a view external to the core the monitor mode is always secure and the monitor 
program is in secure memory. 

Within the non-secure domain there is provided a non-secure operating system 
30 74 and a plurality of non-secure application programs 76, 78 which execute in co- 
operation with the non-secure operating system 74. In the secure domain, a secure 
kernel program 80 is provided. The secure kernel program 80 can be considered to 
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form a secure operating system. Typically such a secure kernel program 80 will be 
designed to provide only those functions which are essential to processing activities 
which must be provided in the secure domain such that the secure kernel 80 can be as 
small and simple as possible since this will tend to make it more secure. A plurality 
of secure applications 82, 84 are illustrated as executing in combination with the 
secure kernel 80. 

Figure 3 illustrates a matrix of processing modes associated with different 
security domains. In this particular example the processing modes are symmetrical 
with respect to the security domain and accordingly Mode 1 and Mode 2 exist in both 
secure and non-secure forms. 

The monitor mode has the highest level of security access in the system and is 
the only mode entitled to switch the system between the non-secure domain and the 
secure domain in either direction. Thus, all domain switches take place via a switch 
to the monitor mode and the execution of the monitor program 72 within the monitor 
mode. 

Figure 4 schematically illustrates another set of non-secure domain processing 
modes 1, 2, 3, 4 and secure domain processing modes a, b, c. In contrast to the 
symmetric arrangement of Figure 3, Figure 4 shows that some of the processing 
modes may not be present in one or other of the security domains. The monitor mode 
86 is again illustrated as straddling the non-secure domain and the secure domain. 
The monitor mode 86 can be considered a secure processing mode, since the secure 
status flag may be changed in this mode and monitor program 72 in the monitor mode 
has the ability to itself set the security status flag it effectively provides the ultimate 
level of security within the system as a whole. 

Figure 5 schematically illustrates another arrangement of processing modes 
with respect to security domains. In this arrangement both secure and non-secure 
domains are identified as well as a further domain. This further domain may be such 
that it is isolated from other parts of a system in a way that it does not need to interact 
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with either of the secure domain or non-secure domain illustrated and as such the 
issue of to which of these it belongs to is not relevant. 

As will be appreciated a processing system, such as a microprocessor is 
5 normally provided with a register bank 88 in which operand values may be stored. 
Figure 6 illustrates a programmer's model view of an example register bank with 
dedicated registers being provided for certain of the register numbers in certain of the 
processing modes. More particularly, the example of Figure 6 is an extension of the 
known ARM register bank (e.g. as provided in ARM7 processors of ARM Limited, 
1 0 Cambridge, England) which is provided with a dedicated saved program status 

register, a dedicated stack pointer register and a dedicated link register R14 for each 
processing mode, but in this case extended by the provision of a monitor mode. As 
illustrated in Figure 6, the fast interrupt mode has additional dedicated registers 
provided such that upon entry of the fast interrupt mode there is no need to save and 
15 then restore register contents from other modes. The monitor mode may in alternative 
embodiments also be provided with dedicated further registers in a similar manner to 
the fast interrupt mode so as to speed up processing of a security domain switch and 
reduce system latency associated with such switches. 

20 Figure 7 schematically illustrates another embodiment in which the register 

bank 88 is provided in the form of two complete and separate register banks that are 
respectively used in the secure domain and the non-secure domain. This is one way in 
which secure data stored within registers operable in the secure domain can be 
prevented from becoming accessible when a switch is made to the non-secure domain. 

25 However, this arrangement hinders the possibility of passing data from the non- 
secure domain to the secure domain as may be permitted and desirable by using the 
fast and efficient mechanism of placing it in a register which is accessible in both the 
non-secure domain and the secure domain. 



An important advantage of having secure register bank is to avoid the need for 
flushing the contents of registers before switching from one world to the other. If 
latency is not a critical issue, a simpler hardware system with no duplicated registers 
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for the secure domain world may be used, e.g. Figure 6. The monitor mode is 
responsible switching from one domain to the other. Restoring context, saving 
previous context, as well as flushing registers is performed by a monitor program at 
least partially executing in monitor mode. The system behaves thus like a 
virtualisation model. This type of embodiment is discussed further below. Reference 
should be made to, for example, the programmer's model of the ARM7 upon winch 
the security features described herein build. 

Processor Modes 

Instead of duplicating modes in secure world, the same modes support both 
secure and non-secure domains (see Figure 8). Monitor mode is aware of the current 
status of the core, either secure or non-secure (e.g. as read from an S bit stored is a 
coprocessor configuration register). 

In the Figure 8, whenever an SMI (Software Monitor Interrupt instruction) 
occurs, the core enters monitor mode to switch properly from one world to the other. 

With reference to Figure 9: 

1 The scheduler launches thread 1 

2 Thread 1 needs to perform a secure function => SMI secure call, the core enters 
nionitor mode. Under hardware control the current PC and CPSR (current processor 
status register) are stored in R14_mon and SPSR_mon (saved processor status register 
for the monitor mode) and IRQ/FIQ interrupts are disabled. 

3. The monitor program does the following tasks: 

- The S bit is set (the secure status flag). 

- Saves at least R14_mon and SPSR_mon in a stack so that non-secure context 

cannot be lost if an exception occurs whilst the secure application is running. 
. Check S thereisanewthreadtolaunch:securethreadl. A mechanism (via thread 
ID table) indicates that thread 1 is active in the secure world. 
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- IRQ/FIQ interrupts are re-enabled. A secure application can then start in 

secure user mode. 

4. Secure thread 1 runs until it finishes, then branches (SMI) onto the 'return from 
secure' function of the monitor program mode (IRQ/FIQ interrupts are then disabled 
when the core enters monitor mode) 

5. The 'return from secure' function does the following tasks: 

- indicates that secure thread 1 is finished (e.g., in the case of a thread ID table, 

remove thread 1 from the table). 

- Restore from stack non-secure context and flush required registers, so that no 

secure data can be read once return has been made to the non-secure domain. 

- Then branches back to the non-secure domain with a SUBS instruction 
(this restores the program counter to the correct point and updates the status flags), 
restoring the PC (from restored R14_mon) and CPSR (from SPSR_mon). So, the 
return point in the non-secure domain is the instruction following the previously 
executed SMI in thread 1 . 

6. Thread 1 executes until the end, then gives the hand back to the scheduler. 

In other embodiments it may be desired not to allow SMIs to occur in user modes. 

Secure World Entry 
Reset 

When a hardware reset occurs, the MMU is disabled and the ARM core (processor) 
branches to secure supervisor mode with the S bit set. Once the secure boot is 
terminated an SMI to go to monitor mode may be executed and the monitor can switch 
to the OS in non-secure world (non-secure svc mode) if desired. If it is desired to use, a 
legacy OS this can simply boo in secure supervisor mode and ignore the secure state. 

SMI INSTRUCTION 

This instruction (a mode switching software interrupt instruction) can be called from 
any non-secure modes in the non-secure domain (as previously mentioned it may be 
desired to restrict SMIs to privileged modes), but the target entry point determined by 
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the associated vector is always fixed and within monitor mode. Its up to the SMI 
handler to branch to the proper secure function that must be run (e.g. controlled by an 
operand passed with the instruction). 

Passing parameters from non-secure world to secure world can be performed 
using the shared registers of the register bank within a Figure 6 type register bank. 

When a SMI occurs in non-secure world, the ARM core may do the following 
actions in hardware: 

- Branch to SMI vector (in secure memory access is allowed since you will now be 
in monitor mode) into monitor mode 

- Save PC into R14_mon and CPSR into SPSR_mon 

- Set the S bit using the monitor program 

- Start to execute secure exception handler in monitor mode (restore/save context in 

case of multi-threads) 

- Branch to secure user mode (or another mode, like svc mode) to execute the 

appropriate function 

- IRQ and FIQ are disabled while the core is in monitor mode (latency is increased) 
Secure World Exit 

There are two possibilities to exit secure world: 

- The secure function is finished and we return into previous non-secure mode that 

had called this function. 

- The secure function is interrupted by a non-secure exception (e.g. IRQ/FIQ/SMI). 

Normal End of Secure Function 

The secure function terminates normally and we need to resume an application in the 
non-secure world at the instruction just after the SMI. In the secure user mode, a C SMT 
instruction is performed to return to monitor mode with the appropriate parameters 
corresponding to a 'return from secure world' routine. At this stage, the registers are 
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flushed to avoid leakage of data between non-secure and secure worlds, then non-secure 
context general purpose registers are restored and non-secure banked registers are 
updated with the value they had in non-secure world. R14_mon and SPSR_mon thus 
get the appropriate values to resume the non-secure application after the SMI, by 
executing a 6 MOVS PC, R14' instruction. 

Exit of Secure Function Due to a Non-Secure Exception 

In this case, the secure function is not finished and the secure context must be saved 
before going into the non-secure exception handler, whatever the interrupts are that need 
to be handled. 

Secure Interrupts 

There are several possibilities for secure interrupts. 
Two possible solutions are proposed which depend on: 

- What kind of interrupt it is (secure or non-secure) 

- What mode the core is in when the IRQ occurs (either in secure or in non-secure 

world) 

Solution One 

In this solution, two distinct pins are required to support secure and non-secure 
interrupts. 

While in Non Secure world, if 

- an IRQ occurs, the core goes to IRQ mode to handle this interrupt as in ARM cores 

such as the ARM7 

- a SIRQ occurs, the core goes to monitor mode to save non-secure context and then 

to a secure IRQ handler to deal with the secure interrupt. 
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While in Secure world, if 

- an SIRQ occurs, the core goes to the secure IRQ handler. The core does not leave 

the secure world 

- an IRQ occurs, the core goes to monitor mode where secure context is saved, then 
5 to a non-secure IRQ handler to deal with this non-secure interrupt. 

In other words, when an interrupt that does not beiong to ihe current world occurs, 
the core goes directly to monitor mode, otherwise it stays in the current world (see 
Figure 10). 

10 

IRQ Occurring in Secure World 

See Figure 11 A: 

15 1 . The scheduler launches thread 1 . 

2. Thread 1 needs to perform a secure function => SMI secure call, the core enters 
monitor mode. Current PC and CPSR are stored in R14_mon and SPSR_mon, 
IRQ/FIQ are disabled. 

3. The monitor handler (program) does the following tasks: 
20 - The S bit is set. 

- Saves at least R14_mon and SPSR_mon in a stack (and possibly other registers are 

also pushed) so that non-secure context cannot be lost if an exception occurs 
whilst the secure application is running. 

- Checks there is a new thread to launch: secure thread 1 . A mechanism (via thread 
25 ID table) indicates that thread 1 is active in the secure world. 

- Secure application can then start in the secure user mode. IRQ/FIQ are 
then re-enabled. 

4. An IRQ occurs while secure thread 1 is running. The core jumps directly to 
monitor mode (specific vector) and stores current PC in R14_rnon and CPSR in 

30 SPSR_mon in monitor mode, (IRQ/FIQ are then disabled). 
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5. Secure context must be saved, previous non-secure context is restored. The 
monitor handler may be to IRQ mode to update R14_irq/SPSR_irq with appropriate 
values and then passes control to a non-secure IRQ handler. 

6. The IRQ handler sen/ices the IRQ, then gives control back to thread 1 in the non- 
secure world. By restoring SPRS_irq and R14_irq into the CPSR and PC, thread 1 is 
now pointing onto the SMI instruction that has been interrupted. 

7. The SMI instruction is re-executed (same instruction as 2). 

8. The monitor handler sees this thread has previously been interrupted, and restores 
the thread 1 context. It then branches to secure thread 1 in user mode, pointing onto 
the instruction that has been interrupted. 

9. Secure thread 1 runs until it finishes, then branches onto the 'return from secure' 
function in monitor mode (dedicated SMI). 

10. The 'return from secure 5 function does the following tasks: 

- indicates that secure thread 1 is finished (i.e., in the case of a thread ID table, 

remove thread 1 from the table). 

- restore from stack non-secure context and flush required registers, so that no secure 

data can be read once a return is made to non-secure world. 
- branches back to the non-secure world with a SUBS instruction, restoring 
the PC (from restored R14_mon) and CPSR (from SPSR_mon). So, the return point 
in the non-secure world should be the instruction following the previously executed 
SMI in thread 1. 

1 1 . Thread 1 executes until the end, then gives control back to the scheduler. 

SIRQ Occurring in Non-Secure World 

See Figure 1 IB: 

1 . The schedule launches thread 1 

2. A SIRQ occurs while secure thread 1 is running. The core jumps directly to 
monitor mode (specific vector) and stores current PC in R14_mon and CPSR in 
SPSR_mon in monitor mode, IRQ/FIQ are then disabled. 

3. Non-Secure context must be saved, then the core goes to a secure IRQ 

handler. 
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4. The IRQ handler services the SIRQ, then gives control back to the monitor mode 
handler using an SMI with appropriate parameters. 

5. The monitor handler restores non-secure context so that a SUBS instruction makes 
the core return to the non-secure world and resumes the interrupted thread 1 . 

6. Thread 1 executes until the end, then gives the hand back to the scheduler. 

The mechanism of Figure 1 1 A has the advantage of providing a deterministic way 
to enter secure world. However, there are some problems associated with interrupt 
priority: e.g. while a SIRQ is running in secure interrupt handler, a non-secure IRQ 
with higher priority may occur. Once the non-secure IRQ is finished, there is a need 
to recreate the SIRQ event so that the core can resume the secure interrupt. 

Solution Two 

In this mechanism (See Figure 12) two distinct pins, or only one, may support 
secure and non-secure interrupts. Having two pins reduces interrupt latency. 

While in Non Secure world, if 

- an IRQ occurs, the core goes to IRQ mode to handle this interrupt like in ARM7 

systems 

- a SIRQ occurs, the core goes to an IRQ handler where an SMI instruction 
will make the core branch to monitor mode to save non-secure context and then to a 
secure IRQ handler to deal with the secure interrupt. 

While in a Secure world, if 

- a SIRQ occurs, the core goes to the secure IRQ handler. The core does not leave 

the secure world 

- an IRQ occurs, the core goes to the secure IRQ handler where an SMI 
instruction will make the core branch to monitor mode (where secure context is 
saved), then to a non-secure IRQ handler to deal with this non-secure interrupt. 



IRQ Occurring In Secure World 



See Figure 13 A: 
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1. The schedule launches thread 1. 

2. Thread 1 needs to perform a secure function => SMI secure call, the core enters 
monitor mode. Current PC and CPSR are stored in R14_mon and SPSR_mon, 
IRQ/FIQ are disabled. 

5 3. The monitor handler does the following tasks: 

- The S bit is set. 

- Saves at least R14_mon and SPSRjnon in a stack (eventually other registers) so 

that non-secure context cannot be lost if an exception occurs whilst the secure 
application is running. 

1 0 - Checks there is a new thread to launch: secure thread 1 . A mechanism (via thread 
ID table) indicates that thread 1 is active in the secure world. 

- Secure application can then start in the secure user mode. IRQ/FIQ are re- 
enabled. 

4. An IRQ occurs while secure thread 1 is running. The core jumps directly to secure 
15 IRQ mode. 

5. The core stores current PC in R14_irq and CPSR in SPSRJrq. The IRQ handler 
detects this is a non-secure interrupt and performs a SMI to enter monitor mode with 
appropriate parameters. 

6. Secure context must be saved, previous non-secure context is restored. The 
monitor handler knows where the SMI came from by reading the CPSR. It can also 
go to IRQ mode to read R14_irq/SPSR_irq to save properly secure context. It can 
also save in these same registers the non-secure context that must be restored once the 
IRQ routine will be finished. 

7. The IRQ handler services the IRQ, then gives control back to thread 1 in the non- 
25 secure world. By restoring SPRS_irq and R14_irq into the CPSR and PC, the core is 

now pointing onto the SMI instruction that has been interrupted. 

8. The SMI instruction is re-executed (same instruction as 2). 

9. The monitor handler sees this thread has previously been interrupted, and restores 
the thread 1 context. It then branches to secure thread 1 in user mode, pointing to the 
instruction that has been interrupted. 

1 0. Secure thread 1 runs until it finishes, then branches onto the 'return from 
secure'; function in monitor mode (dedicated SMI). 



20 
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1 1 . The 'return from secure' function does the following tasks: 

- indicates that secure thread 1 is finished (i.e., in the case of a thread ID table, 

remove thread 1 from the table). 

- restores from stack non-secure context and flushes required registers, so that no 

secure information can be read once we return in non-secure world. 
- branches back to the non-secure world with a SUBS instruction, restoring 
the PC (from restored R14_mon) and CPSR (from SPSR_mon). The return point in 
the non-secure world should be the instruction following the previously executed SMI 
in thread 1 . 

1 1 . Thread 1 executes until the end, then gives the hand back to the scheduler. 
SIRO Occurring in Non-Secure World 

See Figure 13B: 

1 . The schedule launches thread 1 . 

2. A SIRQ occurs while secure thread 1 is running. 

3. The core jumps directly irq mode and stores current PC in R14_irq and CPSR in 
SPSRJrq. IRQ is then disabled. The IRQ handler detects this is a SIRQ and 
performs a SMI instruction with appropriate parameters. 

4. Once in monitor mode, non-secure context must be saved, then the core goes to a 
secure IRQ handler. 

5. The secure IRQ handler services the SIRQ service routine, then gives control back 
to monitor with SMI with appropriate parameters. 

6. The monitor handler restores non-secure context so that a SUBS instruction makes 
the core returns to non-secure world and resumes the interrupted IRQ handler. 

7. The IRQ handler may then return to the non-secure thread by performing a SUBS. 

8. Thread 1 executes until the end, then gives control back to the scheduler. 

With the mechanism of Figure 12, there is no need to recreate the SIRQ event 
in the case of nested interrupts, but there is no guarantee that secure interrupts will be 
performed. 
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Exception Vectors 

At least two physical vector tables are kept (although from a virtual address 
5 point of view they may appear as a single vector table), one for the non-secure world 
in non-secure memory, the one for the secure world in secure memory (not accessible 
from non-secure world). The different virtual to physical memory mappings used in 
the secure and non-secure worlds effectively allow the same virtual memory addresses 
to access different vector tables stored in physical memory. The monitor mode may 
1 0 always use flat memory mapping to provide a third vector table in physical memory. 

If the interrupts follow the Figure 12 mechanism, there would be the following 
vectors shown in Figure 14 for each table. This vector set is duplicated in both secure 
and non-secure memory. 

15 



Exception 


Vector Offset 


Corresponding Mode 


Reset 


0x00 


Supervisor Mode (S bit 
set) 


Undef 


0x04 


Monitor mode/Undef 
mode 


SWI 


0x08 


Supervisor mode/Monitor 
mode 


Prefetch Abort 


OxOC 


Abort mode/Monitor mode 


Data Abort 


0x10 


Abort mode/Monitor Mode 


SMI 


0x14 


Undef mode/Monitor 
mode 


IRQ/SIRQ 


0x18 


IRQ mode 


FIQ 


0x1 C 


FIQ mode 
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NB. The Reset entry is only in the secure vector table. When a Reset is 
performed in non secure world, the core hardware forces entry of supervisor mode and 
setting of the S bit so that the Reset vector can be accessed in secure memory. 

Figure 15 illustrates three exception vector tables respectively applicable to a 
secure mode, a non-secure mode and the monitor mode. These exception vector 
tables may be programmed with exception vectors in order to match the requirements 
and characteristics of the secure and non-secure operating systems. Each of the 
exception vector tables may have an associated vector table base address register 
within CP 15 storing a base address pointing to that table within memory. When an 
exception occurs the hardware will reference the vector table base address register 
corresponding to the current state of the system to determine the base address of the 
vector table to be used. Alternatively, the different virtual to physical memory 
mappings applied in the different modes may be used to separate the three different 
vector table sstored at different physical memory addresses. As illustrated in Figure 
1 6, an exception trap mask register is provided in a system (configuration controlling) 
coprocessor (CP15) associated with the processor core. This exception trap mask 
register provides flags associated with respective exception types. These flags 
indicate whether the hardware should operate to direct processing to either the vector 
for the exception concerned within its current domain or should force a switch to the 
monitor mode (which is a type of secure mode) and then follow the vector in the 
monitor mode vector table. The exception trap mask register (exception control 
register) is only writable from the monitor mode. It may be that read access is also 
prevented to the exception trap mask register when in a non-secure mode. It will be 
seen that the exception trap mask register of Figure 1 6 does not include a flag for the 
reset vector as the system is configured to always force this to jump to the reset vector 
in the secure supervisor mode as specified in the secure vector table in order to ensure 
a secure boot and backwards compatibility. It will be seen that in Figure 15, for the 
sake of completeness, reset vectors have been shown in the vector tables other than 
the secure supervisor mode secure vector table. 
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Figure 16 also illustrates that the flags for the different exception types within the 
exception trap mask register are programmable, such as by the monitor program 
during secure boot. Alternatively, some or all of the flags may in certain 
implementations be provided by physical input signals, e.g. the secure interrupt flag 
SIRQ may be hardwired to always force monitor mode entry and execution of the 
corresponding monitor mode secure interrupt request vector when a secure interrupt 
signal is received. Figure 16 illustrates only that portion of the exception trap register 
concerned with non-secure domain exceptions, a similar set of programmable bits will 
be provided for secure domain exceptions. 

Whilst it will be understood from the above that at one level the hardware acts to 
either force an interrupt to be serviced by the current domain exception handler or the 
monitor mode exception handler depending upon the exception control register flags, 
this is only the first level of control that is applied. As an example, it is possible for 
an exception to occur in the secure mode, the secure mode exception vector to be 
followed to the secure mode exception handler, but this secure mode exception 
handler then decide that the exception is of a nature that it is better dealt with by the 
non-secure exception handler and accordingly utilise an SMI instruction to switch to 
the non-secure mode and invoke the non-secure exception handler. The converse is 
also possible where the hardware might act to initiate the non-secure exception 
handler, but this then execute instructions which direct processing to the secure 
exception handler or the monitor mode exception handler. 



Figure 17 is a flow diagram schematically illustrating the operation of the system 
so as to support another possible type of switching request associated with a new type 
of exception. At step 98 the hardware detects any instruction which is attempting to 
change to monitor mode as indicate in a current program status register (CPSR). 
When such an attempt is detected, then a new type of exception is triggered, this being 
referred to herein as a CPSR violation exception. The generation of this CPSR 
violation exception at step 1 00 results in reference to an appropriate exception vector 
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within the monitor mode and the monitor program is run at step 102 to handle the 
CPSR violation exception. 



It will be appreciated that the mechanisms for initiating a switch between secure 
domain and non-secure domain discussed in relation to Figure 17 may be provided in 
addition to support for the SMI instruction previously discussed. This exception 
mechanism may be provided to respond to unauthorised attempts to switch mode as 
all authorised attempts should be made via an SMI instruction. Alternatively, such a 
mechanism may be legitimate ways to switch between the secure domain and the non- 
secure domain or may be provided in order to give backwards compatibility with 
existing code which, for example, might seek to clear the processing status register as 
part of its normal operation even though it was not truly trying to make an 
unauthorised attempt to switch between the secure domain and the non-secure 
domain. 

A description of an alternative embodiment(s) of the present technique considered 
from a programmer's model view is given below in relation to Figures 18 to 20 as 
follows: 

In the following description, we will use the following terms that must be 
understood in the context of an ARM processor as designed by ARM Limited, of 
Cambridge, England. 

- S bit : Secure state bit, contained in a dedicated CP 15 register. 

- 'Secure/Non-Secure state'. This state is defined by the S bit value. It indicates 
whether the core may access the Secure world (when it is in Secure state, i.e. S=l) or is 
restricted to the Non-secure world only (S=0). Note that the Monitor mode (see further) 
overrides the S bit status. 

- Non-Secure World 1 groups all hardware/software accessible to non-secure 
applications that do not require security. 

- 'Secure World' groups all hardware/software (core, memory. . .) that is only 

accessible when we execute secure code. 

- Monitor mode: new mode that is responsible for switching the core between the 
Secure and Non-secure state. 
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As a brief summary 

- The core can always access the Non-secure world. 

- The core can access the Secure world only when it is in Secure state or 
Monitor mode. 

- SMI: Software Monitor Interrupt: New instruction that will make the core enter the 
Monitor mode through a dedicated SMI exception vector. 'Thread ED': is the identifier 
associated to each thread (controlled by an OS). For some types of OS where the OS 
runs in non-secure world, each time a secure function is called, it will be necessary to 
pass as a parameter the current thread ID to link the secure function to its calling non- 
secure application. The secure world can thus support multi-threads. 

- Secure Interrupt defines an interrupt generated by a Secure peripheral. 

Programmer's model 

Carbon Core Overview 

The concept of the Carbon architecture, which is the term used herein for 
processors using the present techniques, consists in separating two worlds, one secure 
and one non-secure. The secure world must not leak any data to non-secure world. 

In the proposed solution, the secure and non-secure states will share the same 
(existing) register bank. As a consequence, all current modes present in ARM cores 
(Abort, Undef, Irq, User, ...) will exist in each state. 

The core will know it operates in secure or non-secure state thanks to a new 
state bit, the S (secure) bit, instantiated in a dedicated CP 15 register. 

Controlling which instruction or event is allowed to modify the S bit, i.e. to 
change from one state to the other, is a key feature of the security of the system. The 
current solution proposes to add a new mode, the Monitor mode, that will "supervise" 
switching between the two states. The Monitor mode, by writing to the appropriate 
CP 15 register, would be the only one allowed to alter the S bit. 
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Finally, we propose to add some flexibility to the exception handling. All 
exceptions, apart from the reset, would be handled either in the state where they 
happened, or would be directed to the Monitor mode. This would be left configurable 
thanks to a dedicated CP 15 register. 

The details of this solution are discussed in the following paragraphs. 

Processor state and modes 

Carbon new features 

Secure or Non-secure state (S bit) 

One major feature of the Carbon core is the presence of the S bit, which 
indicates whether the core is in a Secure (S=l) or Non-secure (S=0) state. When in 
Secure state, the core would be able to access any data in the Secure or Non-secure 
worlds. When in Non-Secure state, the core would be restricted to the Non-secure 
world only. 

The only exception to this rule concerns the Monitor mode, which overrides 
the S bit information. Even when S=0, the core will perform Secure privileged 
accesses when it is in Monitor mode. See next paragraph, Monitor mode, for further 
information 

The S bit can only be read and written in Monitor mode. Whatever the S bit 
value, if any other mode tries to access it, this will be either ignored or result in an 
Undefined exception. 

All exceptions, apart from Reset, have no effect on the Secure state bit. On 
Reset, the S bit-will be set, and the core will start in Supervisor mode. Refer to the 
boot section for detailed information. 

Secure/Nonsecure states are separate and operate independently of the 
ARM/Thumb/Java states. 
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Monitor mode 

One other important feature of the Carbon system is the creation of a new 
mode, the Monitor mode. This will be used to control the core switching between the 
Secure and Non-secure states . It will always be considered as a secure mode, i.e. 
whatever the value of the S bit, the core will always perform Secure Privileged 
accesses to the external world when it is in Monitor mode. 

Any Secure privileged mode (i.e. privileged modes when S=l) would be able 
to switch to Monitor mode by simply writing the CPSR mode bits (MSR 5 MOVS, or 
equivalent instruction). However, this would be forbidden in any Non-secure mode or 
Secure user mode. If this ever happens, the instruction would be ignored or cause an 
exception. 

There may be a need for a dedicated CPSR violation exception. This exception 
would be raised by any attempt to switch to Monitor mode by directly writing the 
CPSR from any Non-secure mode or Secure user mode. 

All exceptions except Reset are in effect disabled when Monitor mode is 

active: 

• all interrupts are masked; 

• all memory exceptions are either ignored or cause a fatal exception. 

• undefined/SWI/SMI are ignored or cause a fatal exception. 

When entering Monitor mode, the interrupts are automatically disabled and the 
system monitor should be written such that none of the other types of exception can 
happen while the system monitor is running. 

Monitor mode needs to have some private registers. This solution proposes 
that we only duplicate the minimal set of registers, i.e R13 (sp_mon), R14 (Irjnon) 
and SPSR (spsr_mon). 



PO 15379GB 37 

In Monitor mode, the MMU will be disabled (flat address map) as well as the 
MPU or partition checker (the Monitor mode will always perform secure privileged 
external accesses). However, specially programmed MPU region attributes 
(cacheability, ...) would still be active. 

New instruction 

This proposal requires adding one new instruction to the existing ARM 
instruction set. 

The SMI (Software Monitor Interrupt) instruction would be used to enter the 
Monitor mode, branching at a fixed SMI exception vector. This instruction would be 
mainly used to indicate to the Monitor to swap between the Non-secure and Secure 
State. 

As an alternative (or in addition) it would be possible to add a new instruction 
to allow the Monitor mode to save/restore the state of any other mode onto/from the 
Monitor stack to improve context switching performance. 

Processor Modes 

As discussed in the previous paragraph, only one new mode is added in the core, 
the Monitor mode. All existing modes remain available, and will exist both in the 
secure and non-secure states. 

In fact, Carbon users will see the structure illustrated in Figure 1 8. 

Processor registers 

This embodiment proposes that the secure and the non-secure worlds share the 
same register bank. This implies that, when switching from one world to the other 
through the Monitor mode, the system monitor will need to save the first world 
context, and create (or restore) a context in the second world. 

Passing parameters becomes an easy task: any data contained in a register in 
the first world will be available in the same register in the second world once the 
system monitor has switched the S bit. 
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However, apart from a limited number of registers dedicated to passing 
parameters, which will need to be strictly controlled, all other registers will need to be 
flushed when passing from Secure to Non-secure state in order to avoid any leak of 
5 Secure data. This will need to be ensured by the Monitor kernel. 

The possibility of implementing a hardware mechanism or a new instruction to 
directly flush the registers when switching from Secure to Non-secure state is also a 
possibility. 

3 

Another solution proposed involves duplicating all (or most of) the existing 
register bank, thus having two physically separated register banks between the Secure 
and Non-secure state. This solution has the main advantage of clearly separating the 
secure and non-secure data contained in the registers. It also allows fast context 
i switching between the secure and non-secure states. However, the drawback is that 
passing parameters through registers becomes difficult, unless we create some 
dedicated instructions to allow the secure world access the non-secure registers 

Figure 19 illustrates the available registers depending on the processor mode. 
Note that the processor state has no impact on this topic. 

Exceptions 
Secure interrupts 
Current Solution 

It is currently proposed to keep the same interrupt pins as in the current cores, 
i.e. IRQ and FIQ. In association with the Exception Trap Mask register (defined later 
in the document), there should be sufficient flexibility for any system to implement 
and handle different kind of interrupts. 

VIC enhancement 

We could enhance the VIC (Vectored Interrupt Controller) in the following 
way: the VIC may contain one Secure information bit associated to each vectored 
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address. This bit would be programmable by the Monitor or Secure privileged modes 
only. It would indicate whether the considered interrupt should be treated as Secure, 
and thus should be handled on the Secure side. 

We would also add two new Vector Address registers, one for all Secure 
Interrupts happening in Non-Secure state, the other one for all Non-Secure interrupts 
happening in Secure state. 



The S bit information contained in CP 1 5 would be also available to the VIC as 
10 a new VIC input. 

The following table summarizes the different possible scenarios, depending on 
the status of the incoming interrupt (Secure or Non-secure, indicated by the S bit 
associated to each interrupt line) and the state of the core (S bit in CP 15 = S input 
15 signal on the VIC). 





Core in secure state 
(CP15 - S=l) 


Core in Non-secure state 
(CP15 - S=0) 


Secure Interrupt 


No need to switch between worlds. 
The VIC directly presents to the 
core the Secure address associated 
to the interrupt line. The core 
simply has to branch at this address 
where it should find the associated 
[SR. 


The VIC has no Vector associated 
to this interrupt in the Non-secure 
domain. It thus presents to the core 
the address contained in the Vector 
address register dedicated to all 
Secure interrupts occurring in Non- 
secure world. The core, still in Non- 
secure world, then branches to this 
address, where it should find an 
SMI instruction to switch to Secure 
world. Once in Secure world, it 
would be able to have access to the 
correct ISR. 
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, • — 


lVnn-Secure 


The VIC has no Vector associated 


No need to switch between worlds. 


TnterriiDt 


to this interrupt in the Secure 


The VIC directly presents to the 




domain. It thus presents to the core 


core the Non-secure address 




the address contained in the Vector 


associated to the interrupt line. The 




address register dedicated to all 


core simply has to branch at this 




Non-secure interrupts occurring in 


address where it should find the 




Secure world. The core, still in 


associated Non-secure ISR. 




Secure world, then branches to this 






address, where it should find an 






SMI instruction to switch to Non- 






secure world. Once in Non-secure 






world, it would be able to have 






access to the correct ISR. 





Exception handling configurability 

In order to improve Carbon flexibility, a new register, the Exception Trap 
5 Mask, would be added in CP15. This register would contain the following bits: 

- Bit 0: Undef exception (Non-secure state) 

- Bit 1: SWI exception^ (Non-secure state) 

- Bit 2: Prefetch abort exception (Non-secure state) 

- Bit 3: Data abort exception (Non-secure state) 
10 - Bit 4: IRQ exception (Non-secure state) 

- Bit 5: FIQ exception (Non-secure state) 

- Bit 6: SMI exception (both Non-secure/Secure states) 

- Bit 16: Undef exception (Secure state) 

- Bit 17: SWI exception (Secure state) 

15 - Bit 18: Prefetch abort exception (Secure state) 

- Bit 19: Data abort exception (Secure state) 

- Bit 20: IRQ exception (Secure state) 

- Bit 21: FIQ exception (Secure state) 



r 
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The Reset exception does not have any corresponding bit in this register. Reset 
will always cause the core to enter the Secure supervisor mode through its dedicated 
vector. 

5 

If the bit is set, the corresponding exception makes the core enter the Monitor 
mode. Otherwise, the exception will be handled in its corresponding handler in the 
world where it occurred. 

1 0 This register would only be visible in Monitor mode. Any instruction trying to 

access it in any other mode would be ignored. 

This register should be initialized to a system- specific value, depending upon 
whether the system supports a monitor or not. This functionality could be controlled 
15 by a VIC. 

Exception vectors tables 

As there will be separate Secure and Non-secure worlds, we will also need 
separate Secure and Non-secure exception vectors tables. 

20 

Moreover, as the Monitor can also trap some exceptions, we may also need a 
third exception vectors table dedicated to the Monitor. 

The following table summarizes those three different exception vectors tables: 

25 

In non-secure memory: 



Address 


Exception 


Mode 


Automatically accessed when 


0x00 
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0x04 


Undef 


Undef 


Undefined instruction executed when core is 
in Non-Secure state and Exception Trap 
Mask reg [Non-secure Undef] =0 


0x08 


SWI 


Supervisor 


SWI instruction executed when core is in 
Non- Secure state and Exception Trap Mask 
reg [Non-secure SWI]=0 


OxOC 


Prefetch Abort 


Abort 


Aborted instruction when core is in Non- 
Secure state and Exception Trap Mask reg 
[Non-secure PAbort]=0 


0x10 


Data Abort 


Abort 


Aborted data when core is in Non-Secure 
state and Exception Trap Mask reg [Non- 
secure DAbort]=0 


0x14 


Reserved 






0x18 


[RQ 


IRQ 


IRQ pin asserted when core is in Non- 
Secure state and Exception Trap Mask reg 
TST on-secure IRQ]=0 


Oxl C 


FIQ 


FIQ 


7 IQ pin asserted when core is in Non-Secure 
state and Exception Trap Mask reg [Non- 
secure FIQ]=0 



In secure memory: 



Address 


Exception 


Mode 


Automatically accessed when 


0x00 


Reset* 


Supervisor 


Reset pin asserted 


0x04 


Undef 


Undef 


Undefined instruction executed when core is 
in Secure state and Exception Trap Mask reg 
[Secure Undef]=0 


0x08 


SWI 


Supervisor 


SWI instruction executed when core is in 
Secure state and Exception Trap Mask reg 
[Secure SWI]=0 
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OxOC 


Prefetch Abort 


Abort 


Aborted instruction when core is in Secure 
state and Exception Trap Mask reg [Secure 
PAbort]=0 


Ox 10 


Data Abort 


Abort 


Aborted data when core is in Secure state 
and Exception Trap Mask reg [Secure 
Dabort]=0 


0x14 


Reserved 






0x18 


IRQ 


IRQ 


IRQ pin asserted when core is in Secure 
state and Exception Trap Mask reg [Secure 
IRQ]=0 


OxlC 


FIQ 


FIQ 


FIQ pin asserted when core is in Secure state 
and Exception Trap Mask reg [Secure 
FIQ]=0 



* Refer to "Boot" section for further explanation on the Reset mechanism 



In Monitor memory (flat mapping): 



Address 


Exception 


Mode 


Automatically accessed when 


0x00 








0x04 


Undef 


Monitor 


Undefined instruction executed when 
core is in Secure state and Exception Trap 
Mask reg [Secure Undef]=l 
core is in Non-secure state and Exception 
Trap Mask reg [Non-secure Undef]=l 


0x08 


SWI 


Monitor 


SWI instruction executed when 

core is in Secure state and Exception Trap 

Mask reg [Secure SWI]=1 

core is in Non-secure state and Exception 

Trap Mask reg [Non-secure SWI]=1 



r 
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OxOC 


Prefetch Abort 


Monitor 


Aborted instruction when 

core is in Secure state and Exception Trap 

Mask reg [Secure IAbort]=l 

core is in Non-secure state and Exception 

Trap Mask reg [Non-secure Iabort]=l 


OxlO 


Data Abort 


Monitor 


Aborted data when 

core is in Secure state and Exception Trap 
Mask reg [Secure PAbort]=l 
core is in Non-secure state and Exception 
Trap Mask reg [Non-secure Pabort]=l 


0x14 


SMI 


Monitor 




0x18 


IRQ 


Monitor 

( 


- IRQ pin asserted when 

core is in Secure state and Exception Trap 

Mask reg [Secure IRQ]=1 

:ore is in Non-secure state and Exception 

rrap Mask reg [Non-secure IRQ]=1 


OxlC I 


7 IQ I 


Monitor 

c 
IS 
c 
T 


FIQ pin asserted when 

ore is in Secure state and Exception Trap 

/Task reg [Secure FIQ]=1 

ore is in Non-secure state and Exception 

rap Mask reg [Non-secure FIQ]= 1 



In Monitor mode, the exceptions vectors may be duplicated, so that each 
exception will have two different associated vector: 

- One for the exception arising in Non-secure state 

- One for the exception arising in Secure state 



This may be useful to reduce the exception latency, because the monitor kernel 
does not have any more the need to detect the originating state where the exception 
occurred. 



i 
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Note that this feature may be limited to a few exceptions, the SMI being one of the 
most suitable candidates to improve the switching between the Secure and Non-secure 
states. 

Switching between worlds 

When switching between states, the Monitor mode must save the context of the 
first state on its Monitor stack, and restore the second state context from the Monitor 
stack. 

The Monitor mode thus needs to have access to any register of any other modes, 
including the private registers (rl4, SPSR, ..). 

To handle this, the proposed solution consists in giving any privilege mode in 
Secure state the rights to directly switch to Monitor mode by simply writing the 
CPSR. 

With such a system, switching between worlds is performed as follows: 

- enter Monitor mode 

- set the S bit 

- switch to supervisor mode - save the supervisor registers on the MONITOR stack (of 
course the supervisor mode will need to have access to the Monitor stack pointer, but 
this can be easily done, for example by using a common register (RO to R8)) 

- switch to System mode - save the registers (=same as the user mode) on the Monitor 
stack 

- IRQ registers on the Monitor stack 
etc ... for all modes 

- Once all private registers of all modes are saved, revert to Monitor mode with a 
simple MSR instruction (= simply write Monitor value in the CPSR mode field) 

The other solutions have also been considered: 

Add a new instruction that would allow the Monitor to save other modes'private 
registers on its own stack. 
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Implement the Monitor as a new "state", i.e. being able to be in Monitor state (to 
have the appropriate access rights) and in IRQ (or any other) mode, to see the IRQ (or 
any other) private registers. 

Boot mechanism 

The boot mechanism must respect the following features i 

- Keep compatibility with legacy OSes. 

- Boot in most privileged mode to ensure the security of the system. 

As a consequence, Carbon cores will boot in Secure Supervisor mode. 

The different systems will then be: 

- For systems wanting to run legacy OSes, the S bit is not taken into account and the 

core will just see it boots in Supervisor mode. 

- For systems wanting to use the Carbon features, the core boots in Secure privileged 
mode which should be able to configure all secure protections in the system (potentially 
after swapping to Monitor mode) 

Basic Scenario (See Figure 20) 

1. Thread 1 is running in non-secure world (S bit = 0) 

This thread needs to perform a secure function ~> SMI instruction. 

2. The SMI instruction makes the core enter the Monitor mode through a dedicated 

non-secure SMI vector. 
LRmon and SPSR_mon are used to save the PC and CPSR of the non secure mode. 
The S bit remains unchanged (i.e. non-secure state). 
The monitor kernel saves the non-secure context on the monitor. 
It also pushes LR_mon and SPSR_mon, 

The monitor kernel then changes the "S" bit by writing into the CP 15 register. 
It must keep track that a "secure thread 1" will be started in the secure world (e.g. 

by updating a Thread ID table). 
Finally, it exits the monitor mode and switches to secure supervisor mode (MOVS 

instruction after having updated LR_mon and SPSR_mon?). 
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3. The secure kernel dispatches the application to the right secure memory location, 

then switches to user mode (e.g. using a MOVS). 

4. The secure function in executed in secure user mode. Once finished, it calls an 

"exit" function by performing an appropriate SWT 
5 5. The SWI instruction makes the core enter the secure svc mode through a dedicated 
SWI vector, that in turn performs the "exit" function. This "exit" function 
ends with an "SMI" to switch back to monitor mode. 

6. The SMI instruction makes the core enter the monitor mode through a dedicated 

secure SMI vector. 

1 0 LR_mon and SPSR_mon are used to save the PC and CPSR of the Secure svc 
mode. 

The S bit remains unchanged (i.e. Secure State). 

The monitor kernel registers the fact that secure thread 1 is finished (removes the 
secure thread 1 ID from the thread ID table?). 
15 It then changes the "S" bit by writing into the CP 1 5 register, returning to non- 
secure state. 

The monitor kernel restores the non-secure context from the monitor stack. 
It also load the LR_mon and CPSR_mon previously saved in step 2. 
Finally, it exits monitor mode with a SUBS, that will make the core return in non- 
20 secure user mode, on the instruction 

7. Thread 1 can resume normally. 

Figure 21 illustrates in more detail the operation of the memory management 
logic 30 of one embodiment of the present invention. The memory management logic 

25 consists of a Memory Management Unit (MMU) 200 and a Memory Protection Unit 
(MPU) 220. Any memory access request issued by the core 10 that specifies a virtual 
address will be passed over path 234 to the MMU 200, the MMU 200 being 
responsible for performing predetermined access control functions, more particularly 
for determining the physical address corresponding to that virtual address, and for 

30 resolving access permission rights and determining region attributes. 
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The memory system of the data processing apparatus consists of secure 
memory and non-secure memory, the secure memory being used to store secure data 
that is intended only to be accessible by the core 10, or one or more other master 
devices, when that core or other device is operating in a secure mode of operation, and 
is accordingly operating in the secure domain. 

In the embodiment of the present invention illustrated in Figure 21, the 
policing of attempts to access secure data in secure memory by applications running 
on the core 1 0 in non-secure mode is performed by the partition checker 222 within 
the MPU 220, the MPU 220 being managed by the secure operating system, also 
referred to herein as the secure kernel. 

In accordance with preferred embodiments of the present invention a non- 
secure page table 58 is provided within non-secure memory, for example within a 
non-secure memory portion of external memory 56, and is used to store for each of a 
number of non-secure memory regions defined within that page table a corresponding 
descriptor. The descriptor contains information from which the MMU 200 can derive 
access control information required to enable the MMU to perform the predetermined 
access control functions, and accordingly in the embodiment described with reference 
to Figure 21 will provide information about the virtual to physical address mapping, 
the access permission rights, and any region attributes. 

Furthermore, in accordance with the preferred embodiments of the present 
invention, at least one secure page table 58 is provided within secure memory of the 
memory system, for example within a secure part of external memory 56, which again 
for a number of memory regions defined within the table provides an associated 
descriptor. When the processor is operating in a non-secure mode, the non-secure 
page table will be referenced in order to obtain relevant descriptors for use in 
managing memory accesses, whilst when the processor is operating in secure mode, 
descriptors from the secure page table will be used. 
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The retrieval of descriptors from the relevant page table into the MMU 
proceeds as follows. In the event that the memory access request issued by the core 
10 specifies a virtual address, a lookup is performed in the micro-TLB 206 which 
stores for one of a number of virtual address portions the corresponding physical 
address portions obtained from the relevant page table. Hence, the micro-TLB 206 
will compare a certain portion of the virtual address with the corresponding virtual 
address portion stored within the micro-TLB to determine if there is a match. The 
portion compared will typically be some predetermined number of most significant 
bits of the virtual address, the number of bits being dependent on the granularity of the 
pages within the page table 58. The lookup performed within the micro-TLB 206 will 
typically be relatively quick, since the micro-TLB 206 will only include a relatively 
few number of entries, for example eight entries 

In the event that there is no match found within the micro-TLB 206, then the 
memory access request is passed over path 242 to the main TLB 208 which contains a 
number of descriptors obtained from the page tables. As will be discussed in more 
detail later, descriptors from both the non-secure page table and the secure page table 
can co-exist within the main TLB 208, and each entry within the main TLB has a 
corresponding flag (referred to herein as a domain flag) which is settable to indicate 
whether the corresponding descriptor in that entry has been obtained from a secure 
page table or a non-secure page table. In any embodiments where all secure modes of 
operation specify physical addresses directly within their memory access requests, it will 
be appreciated that there will not be a need for such a flag within the main TLB, as the 
main TLB will only store non-secure descriptors. 

Within the main TLB 208, a similar lookup process is performed to determine 
whether the relevant portion of the virtual address issued within the memory, access 
request corresponds with any of the virtual address portions associated with 
descriptors in the main TLB 208 that are relevant to the particular mode of operation. 
Hence, if the core 1 0 is operating in non-secure mode, only those descriptors within 
the main TLB 208 which have been obtained from the non-secure page table will be 
checked, whereas if the core 10 is operating in secure mode, only the descriptors 
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within the main TLB that have been obtained from the secure page table will be 
checked. 

If there is a hit within the main TLB as a result of that checking process, then 
the access control information is extracted from the relevant descriptor and passed 
back over path 242. In particular, the virtual address portion and the corresponding 
physical address portion of the descriptor will be routed over path 242 to the micro- 
TLB 206, for storage in an entry of the micro-TLB, the access permission rights will 
be loaded into the access permission logic 202, and the region attributes will be 
loaded into the region attribute logic 204. The access permission logic 202 and region 
attribute logic 204 may be separate to the micro-TLB, or may be incorporated within 
the micro-TLB. 

At this point, the MMU 200 is then able to process the memory access request 
since there will now be a hit within the micro-TLB 206. Accordingly, the micro-TLB 
206 will generate the physical address, which can then be output over path 238 onto 
the system bus 40 for routing to the relevant memory, this being either on-chip 
memory such as the TCM 36, cache 38, etc, or one of the external memory units 
accessible via the external bus interface 42. At the same time, the access permission 
logic 202 will determine whether the memory access is allowed, and will issue an 
abort signal back to the core 10 over path 230 if it determines that the core is not 
allowed to access the specified memory location in its current mode of operation. For 
example, certain portions of memory, whether in secure memory or non-secure 
memory, may be specified as only being accessible by the core when that core is 
operating in supervisor mode, and accordingly if the core 10 is seeking to access such 
a memory location when in, for example, user mode, the access permission logic 202 
will detect that the core 10 does not currently have the appropriate access rights, and 
will issue the abort signal over path 230. This will cause the memory access to be 
aborted. Finally, the region attribute logic 204 will determine the region attributes for 
the particular memory access, such as whether the access is cacheable, bufferable, etc, 
and will issue such signals over path 232, where they will then be used to determine 
whether the data the subject of the memory access request can be cached, for example 
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within the cache 38, whether in the event of a write access the write data can be 
buffered, etc. 



In the event that there was no hit within the main TLB 208, then the translation 
table walk logic 210 is used to access the relevant page table 58 in order to retrieve the 
required descriptor over path 248, and then pass that descriptor over path 246 to the 
main TLB 208 for storage therein. The base address for both the non-secure page 
table and the secure page table will be stored within registers of CP 15 34, and the 

current domain in which the processor core 10 is operating, i.e. secure domain or non- 

> 

secure domain, will also be set within a register of CP 15, that domain status register 
being set by the monitor mode when a transition occurs between the non-secure 
domain and the secure domain, or vice versa. The content of the domain status 
register will be referred to herein as the domain bit. Accordingly, if a translation table 
walk process needs to be performed, the translation table walk logic 210 will know in 
which domain the core 10 is executing, and accordingly which base address to use to 
access the relevant table. The virtual address is then used as an offset to the base 
address in order to access the appropriate entry within the appropriate page table in 
order to obtain the required descriptor. 

Once the descriptor has been retrieved by the translation table walk logic 210, 
and placed within the main TLB 208, a hit will then be obtained within the main TLB, 
and the earlier described process will be invoked to retrieve the access control 
information, and store it within the micro-TLB 206, the access permission logic 202 
and the region attribute logic 204. The memory access can then be actioned by the 
MMU 200. 

As mentioned earlier, in preferred embodiments, the main TLB 208 can store 
descriptors from both the secure page table and the non-secure page table, but the 
memory access requests are only processed by the MMU 200 once the relevant 
information is stored within the micro-TLB 206. In preferred embodiments, the 
transfer of information between the main TLB 208 and the micro-TLB 206 is 
monitored by the partition checker 222 located within the MPU 220 to ensure that, in 
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the event that the core 10 is operating in a non-secure mode, no access control 
information is transferred into the micro-TLB 206 from descriptors in the main TLB 
208 if that would cause a physical address to be generated which is within secure 
memory. 

5 

The memory protection unit is managed by the secure operating system, which 
is able to set within registers of the CP 15 34 partitioning information defining the 
partitions between the secure memory and the non-secure memory. The partition 
checker 222 is then able to reference that partitioning information in order to 
10 determine whether access control information is being transferred to the micro-TLB 
206 which would allow access by the core 10 in a non-secure mode to secure memory. 
More particularly, in preferred embodiments, when the core 10 is operating in a non- 
secure mode of operation, as indicated by the domain bit set by the monitor mode 
within the CP 15 domain status register, the partition checker 222 is operable to 
15 monitor via path 244 any physical address portion seeking to be retrieved into the 
micro-TLB 206 from the main TLB 208 and to determine whether the physical 
address that would then be produced for the virtual address based on that physical 
address portion would be within the secure memory. In such circumstances, the 
partition checker 222 will issue an abort signal over path 230 to the core 10 to prevent 
20 the memory access from taking place. 

It will be appreciated that in addition the partition checker 222 can be arranged 
to actually prevent that physical address portion from being stored in the micro-TLB 
206 or alternatively the physical address portion may still be stored within the micro- 
25 TLB 206, but part of the abort process would be to remove that incorrect physical 
address portion from the micro-TLB 206, for example by flushing the micro-TLB 206. 

Whenever the core 10 changes via the monitor mode between a non-secure 
30 mode and a secure mode of operation, the monitor mode will change the value of the 
domain bit within the CP 15 domain status register to indicate the domain into which 
the processor's operation is changing. As part of the transfer process between 
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domains, the micro-TLB 206 will be flushed and accordingly the first memory access 
following a transition between secure domain and non-secure domain will produce a 
miss in the micro-TLB 206, and require access information to be retrieved from main 
TLB 208, either directly, or via retrieval of the relevant descriptor from the relevant 
page table. 

By the above approach, it will be appreciated that the partition checker 222 
will ensure that when the core is operating in the non-secure domain, an abort of a 
memory access will be generated if an attempt is made to retrieve into the micro-TLB 
206 access control information that would allow access to secure memory. 

If in any modes of operation of the processor core 10, the memory access 
request is arranged to specify directly a physical address, then in that mode of 
operation the MMU 200 will be disabled, and the physical address will pass over path 
236 into the MPU 220. In a secure mode of operation, the access permission logic 
224 and the region attribute logic 226 will perform the necessary access permission 
and region attribute analysis based on the access permission rights and region 
attributes identified for the corresponding regions within the partitioning information 
registers within the CP15 34. If the secure memory location seeking to be accessed is 
within a part of secure memory only accessible in a certain mode of operation, for 
example secure privileged mode, then an access attempt by the core in a different 
mode of operation, for example a secure user mode, will cause the access permission 
logic 224 to generate an abort over path 230 to the core in the same way that the 
access permission logic 202 of the MMU would have produced an abort in such 
circumstances. Similarly, the region attribute logic 226 will generate cacheable and 
bufferable signals in the same way that the region attribute logic 204 of the MMU 
would have generated such signals for memory access requests specified with virtual 
addresses. Assuming the access is allowed, the access request will then proceed over 
path 240 onto the system bus 40, from where it is routed to the appropriate memory 
unit. 
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For a non-secure access where the access request specifies a physical address, 
the access request will be routed via path 236 into the partition checker 222, which 
will perform partition checking with reference to the partitioning information in the 
CP 15 registers 34 in order to determine whether the physical address specifies a 
location within secure memory, in which event the abort signal will again be 
generated over path 230. 

The above described processing of the memory management logic will now be 
described in more detail with reference to the flow diagrams of Figures 23 and 24. 
Figure 23 illustrates the situation in which the program running on the core 10 
generates a virtual address, as indicated by step 300. The relevant domain bit within 
the CP 15 domain status register 34 as set by the monitor mode will indicate whether 
the core is currently running in a secure domain or the non-secure domain. In the 
event that the core is running in the secure domain, the process branches to step 302, 
where a lookup is performed within the micro-TLB 206 to see if the relevant portion 
of the virtual address matches with one of the virtual address portions within the 
micro-TLB. In the event of a hit at step 302, the process branches directly to step 312, 
where the access permission logic 202 performs the necessary access permission 
analysis. At step 314, it is then determined whether there is an access permission 
violation, and if there is the process proceeds to step 3 1 6, where the access permission 
logic 202 issues an abort over path 230. Otherwise, in the absence of such an access 
permission violation, the process proceeds from step 314 to step 318, where the 
memory access proceeds. In particular the region attribute logic 204 will output the 
necessary cacheable and bufferable attributes over path 232, and the micro-TLB 206 
will issue the physical address over path 238 as described earlier. 

If at step 302 there is a miss in the micro-TLB, then a lookup process is 
performed within the main TLB 208 at step 304 to determine whether the required 
secure descriptor is present within the main TLB. If not, then a page table walk 
process is executed at step 306, whereby the translation table walk logic 210 obtains 
the required descriptor from the secure page table, as described earlier with reference 
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to Figure 21. The process then proceeds to step 308, or proceeds directly to step 308 
from step 304 in the event that the secure descriptor was already in the main TLB 208. 

At step 308, it is determined that the main TLB now contains the valid tagged 
5 secure descriptor, and accordingly the process proceeds to step 310, where the micro- 
TLB is loaded with the sub-section of the descriptor that contains the physical address 
portion. Since the core 10 is currently running in secure mode, there is no need for the 
partition checker 222 to perform any partition checking function. 

10 The process then proceeds to step 312 where the remainder of the memory 

access proceeds as described earlier. 

In the event of a non-secure memory access, the process proceeds from step 
300 to step 320, where a lookup process is performed in the micro-TLB 206 to 

15 determine whether the corresponding physical address portion from a non-secure 
descriptor is present. If it is, then the process branches directly to step 336, where the 
access permission rights are checked by the access permission logic 202. It is 
important to note at this point that if the relevant physical address portion is within the 
micro-TLB, it is assumed that there is no security violation, since the partition checker 

20 222 effectively polices the information prior to it being stored within the micro-TLB, 
such that if the information is within the micro-TLB, it is assumed to be the 
appropriate non-secure information. Once the access permission has been checked at 
step 336, the process proceeds to step 338, where it is determined whether there is any 
violation, in which event an access permission fault abort is issued at step 316. 

25 Otherwise, the process proceeds to step 318 where the remainder of the memory 
access is performed, as discussed earlier. 

In the event that at step 320 no hit was located in the micro-TLB, the process 
proceeds to step 322, where a lookup process is performed in the main TLB 208 to 
30 determine whether the relevant non-secure descriptor is present. If not, a page table 
walk process is performed at step 324 by the translation table walk logic 210 in order 
to retrieve into the main TLB 208 the necessary non-secure descriptor from the non- 
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secure page table. The process then proceeds to step 326, or proceeds directly to step 
326 from step 322 in the event that a hit within the main TLB 208 occurred at step 
322. At step 326 5 it is determined that the main TLB now contains the valid tagged 
non-secure descriptor for the virtual address in question, and then at step 328 the 
5 partition checker 222 checks that the physical address that would be generated from 
the virtual address of the memory access request (given the physical address portion 
within the descriptor) will point to a location in non-secure memory. If not, i.e. if the 
physical address points to a location in secure memory, then at step 330 it is 
determined that there is a security violation, and the process proceeds to step 332 
1 0 where a secure/non-secure fault abort is issued by the partition checker 222. 

If however the partition checker logic 222 determines that there is no security 
violation, the process proceeds to step 334, where the micro-TLB is loaded with the 
sub-section of the relevant descriptor that contains the physical address portion, 
15 whereafter at step 336 the memory access is then processed in the earlier described 
manner. 

The handling of memory access requests that directly issue a physical address 
will now be described with reference to Figure 24. As mentioned earlier, in this 

20 scenario, the MMU 200 will be deactivated, this preferably being achieved by the 
setting within a relevant register of the CP 15 registers an MMU enable bit, this setting 
process being performed by the monitor mode. Hence, at step 350 the core 10 will 
generate a physical address which will be passed over path 236 into the MPU 220. 
Then, at step 352, the MPU checks permissions to verify that the memory access 

25 being requested can proceed given the current mode of operation, i.e. user, supervisor, 
etc. Furthermore, if the core is operating in non-secure mode, the partition checker 
222 will also check at step 352 whether the physical address is within non-secure 
memory. Then, at step 354, it is determined whether there is a violation, i.e. whether 
the access permission processing has revealed a violation, or if in non-secure mode, 

30 the partition checking process has identified a violation. If either of these violations 
occurs, then the process proceeds to step 356 where an access permission fault abort is 
generated by the MPU 220. It will be appreciated that in certain embodiments there 
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may be no distinction between the two types of abort, whereas in alternative 
embodiments the abort signal could indicate whether it relates to an access permission 
fault or a security fault. 

If no violation is detected at step 354, the process proceeds to step 358, where 
the memory access to the location identified by the physical address occurs. 

In preferred embodiments only the monitor mode is arranged to generate 
physical addresses directly, and accordingly in all other cases the MMU 200 will be 
active and generation of the physical address from the virtual address of the memory 
access request will occur as described earlier. 

Figure 22 illustrates an alternative embodiment of the memory management 
logic in a situation where all memory access requests specify a virtual address, and 
accordingly physical addresses are not generated directly in any of the modes of 
operation. In this scenario, it will be appreciated that a separate MPU 220 is not 
required, and instead the partition checker 222 can be incorporated within the MMU 
200. This change aside, the processing proceeds in exactly the same manner as 
discussed earlier with reference to Figures 21 and 23. 

It will be appreciated that various other options are also possible. For example, 
assuming memory access requests may be issued by both secure and non-secure 
modes specifying virtual addresses, two MMUs could be provided, one for secure 
access requests and one for non-secure access requests, i.e. MPU 220 in Figure 21 
could be replaced by a complete MMU. In such cases, the use of flags with the main 
TLB of each MMU to define whether descriptors are secure or non-secure would not 
be needed, as one MMU would store non-secure descriptors in its main TLB, and the 
other MMU would store secure descriptors in its main TLB. Of course, the partition 
checker would still be required to check whether an access to secure memory is being 
attempted whilst the core is in the non-secure domain. 
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If, alternatively, all memory access requests directly specified physical 
addresses, an alternative implementation might be to use two MPUs, one for secure 
access requests and one for non-secure access requests. The MPU used for non-secure 
access requests would have its access requests policed by a partition checker to ensure 
5 accesses to secure memory are not allowed in non-secure modes. 

As a further feature which may be provided with either the Figure 2 1 or the 
Figure 22 arrangement, the partition checker 222 could be arranged to perform some 
partition checking in order to police the activities of the translation table walk logic 

10 2 1 0. In particular, if the core is currently operating in the non-secure domain, then the 
partition checker 222 could be arranged to check, whenever the translation table walk 
logic 210 is seeking to access a page table, that it is accessing the non-secure page 
table rather than the secure page table. If a violation is detected, an abort signal would 
preferably be generated. Since the translation table walk logic 210 typically performs 

1 5 the page table lookup by combining a page table base address with certain bits of the 
virtual address issued by the memory access request, this partition checking may 
involve, for example, checking that the translation table walk logic 210 is using a base 
address of a non-secure page table rather than a base address of a secure page table. 

20 Figure 25 illustrates schematically the process performed by the partition 

checker 222 when the core 10 is operating in a non-secure mode. It will be 
appreciated that in normal operation a descriptor obtained from the non-secure page 
table should describe a page mapped in non-secure memory only. However, in the 
case of software attack, the descriptor may be tampered with in order that it now 

25 describes a section that contains both non-secure and secure regions of memory. 
Hence, considering the example in Figure 25, the corrupted non-secure descriptor may 
cover a page that includes non-secure areas 370, 372, 374 and secure areas 376, 378, 
380. If the virtual address issued as part of the memory access request would then 
correspond to a physical address in a secure memory region, for example the secure 
30 memory region 376 as illustrated in Figure 25, then the partition checker 222 is 
arranged to generate an abort to prevent that access taking place. Hence, even though 
the non-secure descriptor has been corrupted in an attempt to gain access to secure 
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memory, the partition checker 222 prevents the access taking place. In contrast, if the 
physical address that would be derived using this descriptor corresponds to a non- 
secure memory region, for example region 374 as illustrated in Figure 25, then the 
access control information loaded into the micro-TLB 206 merely identifies this non- 
5 secure region 374. Hence, accesses within that non-secure memory region 374 can 
occur but no accesses into any of the secure regions 376, 378 or 380 can occur. Thus, 
it can be seen that even though the main TLB 208 may contain descriptors from the 
non-secure page table that have been tampered with, the micro-TLB will only contain 
physical address portions that will enable access to non-secure memory regions. 

10 

As described earlier, in embodiments where both non-secure modes and secure 
modes may generate memory access requests specifying virtual addresses, then the 
memory preferably comprises both a non-secure page table within non-secure 
memory, and a secure page table within secure memory. When in non-secure mode, 

15 the non-secure page table will be referenced by the translation table walk logic 210, 
whereas when in secure mode, the secure page table will be referenced by the 
translation table walk logic 210. Figure 26 illustrates these two page tables. As 
shown in Figure 26, the non-secure memory 390, which may for example be within 
external memory 56 of Figure 1, includes within it a non-secure page table 395 

20 specified in a CP 15 register 34 by reference to a base address 397. Similarly, within 
secure memory 400, which again may be within the external memory 56 of Figure 1, a 
corresponding secure page table 405 is provided which is specified within a duplicate 
CP 15 register 34 by a secure page table base address 407. Each descriptor within the 
non-secure page table 395 will point to a corresponding non-secure page in non-secure 

25 memory 390, whereas each descriptor within the secure page table 405 will define a 
corresponding secure page in the secure memory 400. In addition, as will be 
described in more detail later, it is possible for certain areas of memory to be shared 
memory regions 410, which are accessible by both non-secure modes and secure 
modes. 

30 

Figure 27 illustrates in more detail the lookup process performed within the 
main TLB 208 in accordance with preferred embodiments. As mentioned earlier, the 
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main TLB 208 includes a domain flag 425 which identifies whether the corresponding 
descriptor 435 is from the secure page table or the non-secure page table. This 
ensures that when a lookup process is performed, only the descriptors relevant to the 
particular domain in which the core 10 is operating will be checked. Figure 27 
illustrates an example where the core is running in the secure domain, also referred to 
as the secure world. As can be seen from Figure 27, when a main TLB 208 lookup is 
performed, this will result in the descriptors 440 being ignored, and only the 
descriptors 445 being identified as candidates for the lookup process. 

In accordance with preferred embodiments, an additional process ID flag 430, 
also referred to herein as the ASID flag, is provided to identify descriptors from 
process specific page tables. Accordingly, processes PI, P2 and P3 may each have 
corresponding page tables provided within the memory, and further may have 
different page tables for non-secure operation and secure operation. Further, it will be 
appreciated that the processes PI, P2 5 P3 in the secure domain may be entirely 
separate processes to the processes PI, P2, P3 in the non-secure domain. 
Accordingly, as shown in Figure 27, in addition to checking the domain when a main 
TLB lookup 208 is required, the ASID flag is also checked. 

Accordingly, in the example in Figure 27 where in the secure domain, process 
PI is executing, this lookup process identifies just the two entries 450 within the main 
TLB 208, and a hit or miss is then generated dependent on whether the virtual address 
portion within those two descriptors matches with the corresponding portion of the 
virtual address issued by the memory access request. If it does, then the relevant 
access control information is extracted and passed to the micro-TLB 206, the access 
permission logic 202 and the region attribute logic 204. Otherwise, a miss occurs, and 
the translation table walk logic 210 is used to retrieved into the main TLB 208 the 
required descriptor from the page table provided for secure process PI. As will be 
appreciated by those skilled in the art, there are many techniques for managing the 
content of a TLB, and accordingly when a new descriptor is retrieved for storage in 
the main TLB 208, and the main TLB is already full, any one of a number of known 
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techniques may be used to determine which descriptor to evict from the main TLB to 
make room for the new descriptor, for example least recently used approaches, etc. 



It will be appreciated that the secure kernel used in secure modes of operation 
may be developed entirely separately to the non-secure operating system. However, in 
certain cases the secure kernel and the non-secure operating system development may 
be closely linked, and in such situations it may be appropriate to allow secure 
applications to use the non-secure descriptors. Indeed, this will allow the secure 
applications to have direct access to non-secure data (for sharing) by knowing only the 
virtual address. This of course presumes that the secure virtual mapping and the non- 
secure virtual mapping are exclusive for a particular ASID. In such scenarios, the tag 
introduced previously (i.e. the domain flag) to distinguish between secure and non- 
secure descriptors will not be needed. The lookup in the TLB is instead then 
performed with all of descriptors available. 

In preferred embodiments, the choice between this configuration of the main 
TLB, and the earlier described configuration with separate secure and non-secure 
descriptors, can be set by a particular bit provided within the CP 15 control registers. 
In preferred embodiments, this bit would only be set by the secure kernel. 

In. embodiments where the secure application were directly allowed to use a 
non-secure virtual address, it would be possible to make a non-secure stack pointer 
available from the secure domain. This can be done by copying a non-secure register 
value identifying the non-secure stack pointer into a dedicated register within the 
CP 15 registers 34. This will then enable the non-secure application to pass 
parameters via the stack according to a scheme understood by the secure application. 

As described earlier, the memory may be partitioned into non-secure and 
secure parts, and this partitioning is controlled by the secure kernel using the CP 15 
registers 34 dedicated to the partition checker 222. The basic partitioning approach is 
based on region access permissions as definable in typical MPU devices. 
Accordingly, the memory is divided into regions, and each region is preferably 
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defined with its base address, size, memory attributes and access permissions. 
Further, when overlapping regions are programmed, the attributes of the upper region 
take highest priority. Additionally, in accordance with preferred embodiments of the 
present invention, a new region attribute is provided to define whether that 
corresponding region is in secure memory or in non-secure memory. This new region 
attribute is used by the secure kernel to define the part of the memory that is to be 
protected as secure memory. 

At the boot stage, a first partition is performed as illustrated in Figure 28. This 
initial partition will determine the amount of memory 460 allocated to the non-secure 
world, non-secure operating system and non-secure applications. This amount 
corresponds to the non-secure region defined in the partition. This information will 
then be used by the non-secure operating system for its memory management. The 
rest of the memory 462, 464, which is defined as secure, is unknown by the non- 
secure operating system. In order to protect integrity in the non-secure world, the non- 
secure memory may be programmed with access permission for secure privileged 
modes only. Hence, secure applications will not corrupt the non-secure ones. As can 
be seen from Figure 28, following this boot stage partition, memory 460 is available 
for use by the non-secure operating system, memory 462 is available for use by the 
secure kernel, and memory 464 is available for use by secure applications. 

Once the boot stage partition has been performed, memory mapping of the 
non-secure memory 460 is handled by the non-secure operating system using the 
MMU 200, and accordingly a series of non-secure pages can be defined in the usual 
manner. This is illustrated in Figure 29. 

If a secure application needs to share memory with a non-secure application, 
the secure kernel can change the rights of a part of the memory to transfer artificially 
data from one domain to the other. Hence, as illustrated in Figure 30, the secure 
kernel can, after checking the integrity of a non-secure page, change the rights of that 
page such that it becomes a secure page 466 accessible as shared memory. 
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When the partition of the memory is changed, the micro-TLB 206 needs to be 
flushed. Hence, in this scenario, when a non-secure access subsequently occurs, a 
miss will occur in the micro-TLB 206, and accordingly a new descriptor will be 
loaded from the main TLB 208. This new descriptor will subsequently be checked by 
the partition checker 222 of the MPU as it is attempted to retrieve it into the micro- 
TLB 206, and so will be consistent with the new partition of the memory. 

In preferred embodiments, the cache 38 is virtual-indexed and physical-tagged. 
Accordingly, when an access is performed in the cache 38, a lookup will have already 
been performed in the micro-TLB 206 first, and accordingly access permissions, 
especially secure and non-secure permissions, will have been checked. Accordingly, 
secure data cannot be stored in the cache 38 by non-secure applications. Access to the 
cache 38 is under the control of the partition checking performed by the partition 
checker 222, and accordingly no access to secure data can be performed in non-secure 
mode. 

However, one problem that could occur would be for an application in the 
non-secure domain to be able to use the cache operations register to invalidate, clean, 
or flush the cache. It needs to be ensured that such operations could not affect the 
security of the system. For example, if the non-secure operating system were to 
invalidate the cache 38 without cleaning it, any secure dirty data must be written to the 
external memory before being replaced. Preferably, secure data is tagged in the cache, 
and accordingly can be dealt with differently if desired. 

In preferred embodiments, if an "invalidate line by address" operation is 
executed by a non-secure program, the physical address is checked by the partition 
checker 222, and if the cache line is a secure cache line, the operation becomes a 
"clean and invalidate" operation, thereby ensuring that the security of the system is 
maintained. Further, in preferred embodiments, all "invalidate line by index" 
operations that are executed by a non-secure program become "clean and invalidate by 
index" operations. Similarly, all "invalidate all" operations executed by a non-secure 
program become "clean and invalidate all" operations. 
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Furthermore, with reference to Figure 1, any access to the TCM 36 by the 
DMA 32 is controlled by the micro-TLB 206. Hence, when the DMA 32 performs a 
lookup in the TLB to translate its virtual address into a physical one, the earlier 
described flags that were added in the main TLB allow the required security checking 
to be performed, just as if the access request had been issued by the core 10. Further, 
as will be discussed later, a replica partition checker is coupled to the external bus 70, 
preferably being located within the arbiter/decoder block 54, such that if the DMA 32 
directly accesses the memory coupled to the external bus 70 via the external bus 
interface 42, the replica partition checker connected to that external bus checks the 
validity of the access. Furthermore, in certain preferred embodiments, it would be 
possible to add a bit to the CP 15 registers 34 to define whether the DMA controller 32 
can be used in the non-secure domain, this bit only being allowed to be set by the 
secure kernel when operating in a privileged mode. 

Considering the TCM 36, if secure data is to placed within the TCM 36, this 
must be handled with care. As an example, a scenario could be imagined where the 
non-secure operating system programs the physical address range for the TCM 
memory 36 so that it overlaps an external secure memory part. If the mode of 
operation then changes to a secure mode, the secure kernel may cause data to be 
stored in that overlapping part, and typically the data would be stored in the TCM 36, 
since the TCM 36 will typically have a higher priority than the external memory. If 
the non-secure operating system were then to change the setting of the physical 
address space for the TCM 36 so that the previous secure region is now mapped in a 
non-secure physical area of memory, it will be appreciated that the non-secure 
operating system can then access the secure data, since the partition checker will see 
the area as non-secure and won't assert an abort. Hence, to summarise, if the TCM is 
configured to act as normal local RAM and not as SmartCache, it may be possible for 
the non-secure operating system to read secure world data if it can move the TCM 
base register to non-secure physical address. 

To prevent this kind of scenario, a control bit is in preferred embodiments 
provided within the CP 15 registers 34 which is only accessible in secure privilege 



\ 



r 

P015379GB 65 

modes of operation, and provides two possible configurations. In a first 
configuration, this control bit is set to "1", in which event the TCM can only be 
controlled by the secure privilege modes. Hence, any non-secure access attempted to 
the TCM control registers within the CP 15 34 will cause an undefined instruction 
5 exception to be entered. Thus, in this first configuration, both secure modes and non- 
secure modes can use the TCM, but the TCM is controlled only by the secure 
privilege mode. In the second configuration, the control bit is set to "0", in which 
event the TCM can be controlled by the non-secure operating system. In this case, the 
TCM is only used by the non-secure applications. No secure data can be stored to or 
10 loaded from the TCM. Hence, when a secure access is performed, no look-up is 
performed within the TCM to see if the address matched the TCM address range. 

By default, it is envisaged that the TCM would be used only by non-secure 
15 operating systems, as in this scenario the non-secure operating system would not need 
to be changed. 

As mentioned earlier, in addition to the provision of the partition checker 222 
within the MPU 220, preferred embodiments of the present invention also provide an 

20 analogous partition checking block coupled to the external bus 70, this additional 
partition checker being used to police accesses to memory by other master devices, for 
example the digital signal processor (DSP) 50, the DMA controller 52 coupled 
directly to the external bus, the DMA controller 32 connectable to the external bus via 
the external bus interface 42, etc. As mentioned earlier, the entire memory system can 

25 consist of several memory units, and a variety of these may exist on the external bus 
70, for example the external memory 56, boot ROM 44, or indeed buffers or registers 
48, 62, 66 within peripheral devices such as the screen driver 46, I/O interface 60, key 
storage unit 64, etc. Furthermore, different parts of the memory system may need to 
be defined as secure memory, for example it may be desired that the key buffer 66 

30 within the key storage unit 64 should be treated as secure memory. If an access to 
such secure memory were to be attempted by a device coupled to the external bus, 
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then it is clear that the earlier described memory management logic 30 provided 
within the chip containing the core 10 would not be able to police such accesses. 



Figure 3 1 illustrates how the additional partition checker 492 coupled to the 
external bus, also referred to herein as the device bus, is used. The external bus would 
typically be arranged such that whenever memory access requests were issued onto 
that external bus by devices, such as devices 470, 472, those memory access requests 
would also include certain signals on the external bus defining the mode of operation, 
for example privileged, user, etc. In accordance with preferred embodiments of the 
present invention the memory access request also involves issuance of a domain 
signal onto the external bus to identify whether the device is operating in secure mode 
or non-secure mode. This domain signal is preferably issued at the hardware level, 
and in preferred embodiments a device capable of operating in secure or non-secure 
domains will include a predetermined pin for outputting the domain signal onto path 
490 within the external bus. For the purpose of illustration, this path 490 is shown 
separately to the other signal paths 488 on the external bus. 

This domain signal, also referred to herein as the "S bit 5 ' will identify whether 
the device issuing the memory access request is operating in secure domain or non- 
secure domain, and this information will be received by the partition checker 492 
coupled to the external bus. The partition checker 492 will also have access to the 
partitioning information identifying which regions of memory are secure or non- 
secure, and accordingly can be arranged to only allow a device to have access to a 
secure part of memory if the S bit is asserted to identify a secure mode of operation. 

By default, it is envisaged that the S bit would be unasserted, and accordingly 
a pre-existing non-secure device, such as device 472 illustrated in Figure 31, would 
not output an asserted S bit and accordingly would never be granted access by the 
partition checker 492 to any secure parts of memory, whether that be within registers 
or buffers 482, 486 within the screen driver 480, the I/O interface 484, or within the 
external memory 474. 
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For the sake of illustration, the arbiter block 476 used to arbitrate between 
memory access requests issued by master devices, such as devices 470, 472, is 
illustrated separately to the decoder 478 used to determine the appropriate memory 
device to service the memory access request, and separate from the partition checker 
492. However, it will be appreciated that one or more of these components may be 
integrated within the same unit if desired. 

Figure 32 illustrates an alternative embodiment, in which a partition checker 
492 is not provided, and instead each memory device 474, 480, 484 is arranged to 
police its own memory access dependent on the value of the S bit. Accordingly, if 
device 470 were to assert a memory access request in non-secure mode to a register 
482 within the screen driver 480 that was marked as secure memory, then the screen 
driver 480 would determine that the S bit was not asserted, and would not process the 
memory access request. Accordingly, it is envisaged that with appropriate design of 
the various memory devices, it may be possible to avoid the need for a partition 
checker 492 to be provided separately on the external bus. 

Figure 33 shows different modes and applications running on a processor. The 
dashed lines indicate how different modes and/or applications can be separated and 
isolated from one another during monitoring of the processor according to an 
embodiment of the present invention. 

The ability to monitor a processor to locate possible faults and discover why 
an application is not performing as expected is extremely useful and many processors 
provide such functions. The monitoring can be performed in a variety of ways 
including debug and trace functions. 

In the processor according to the present technique debug can operate in 
several modes including halt debug mode and monitor debug mode. These modes are 
intrusive and cause the program running at the time to be stopped. In halt debug 
mode, when a breakpoint or watchpoint occurs, the core is stopped and isolated from 
the rest of the system and the core enters debug state. On entry the core is halted, the 
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pipeline is flushed and no instructions are pre-fetched. The PC is frozen and any 
interrupts (IRQ and FIQ) are ignored. It is then possible to examine the core internal 
state (via the JTAG serial interface) as well as the state of the memory system. This 
state is invasive to program execution, as it is possible to modify current mode, 
5 change register contents, etc. Once Debug is terminated, the core exits from the 
Debug State by scanning in . the Restart instruction through the Debug TAP (test 
access port). Then the program resumes execution. 

In monitor debug mode, a breakpoint or watchpoint causes the core to enter 
0 abort mode, taking prefetch or Data Abort vectors respectively. In this case, the core 
is still in a functional mode and is not stopped as it is in Halt debug mode. The abort 
handler communicates with a debugger application to access processor and 
coprocessor state or dump memory. A debug monitor program interfaces between the 
debug hardware and the software debugger. If bit 1 1 of the debug status and control 
5 register DSCR is set (see later), interrupts (FIQ and IRQ) can be inhibited. In monitor 
debug mode, vector catching is disabled on Data Aborts and Prefetch Aborts to avoid 
the processor being forced into an unrecoverable state as a result of the aborts that are 
generated for the monitor debug mode. It should be noted that monitor debug mode is 
a type of debug mode and is not related to monitor mode of the processor which is the 
mode that supervises switching between secure world and non-secure world. 

Debug can provide a snapshot of the state of a processor at a certain moment. 
It does this by noting the values in the various registers at the moment that a debug 
initiation request is received. These values are recorded on a scan chain (541, 544 of 
Figure 41) and they are then serially output using a JTAG controller (18 or Figure 1). 

An alternative way of monitoring the core is by trace. Trace is not intrusive 
and records subsequent states as the core continues to operate. Trace runs on an 
embedded trace macrocell (ETM) 22, 26 of Figure 1. The ETM has a trace port 
through which the trace information is exported, this is then analysed by an external 
trace port analyser. 
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The processor of embodiments of the present technique operates in two 
separate domains, in the embodiments described these domains comprise secure and 
non-secure domains. However, for the purposes of the monitoring functions, it will 
be clear to the skilled person that these domains can be any two domains between 
which data should not leak. Embodiments of the present technique are concerned 
with preventing leakage of data between the two domains and monitoring functions 
such as debug and trace which are conventionally allowed access to the whole system 
are a potential source of data leakage between the domains. 

In the example given above of a secure and non-secure domain or world, 
secure data must not be available to the non-secure world. Furthermore, if debug is 
permitted, in secure world, it may be advantageous for some of the data within secure 
world to be restricted or hidden. The hashed lines in Figure 33 shows some examples 
of possible ways to segment data access and provide different levels of granularity. In 
Figure 33, monitor mode is shown by block 500 and is the most secure of all the 
modes and controls switching between secure and non-secure worlds. Below monitor 
mode 500 there is a supervisor mode, this comprises secure supervisor mode 510 and 
non-secure supervisor mode 520. Then there is non-secure user mode having 
applications 522 and 524 and secure user mode with applications 512, 514 and 516. 
The monitoring modes (debug and trace) can be controlled to only monitor non-secure 
mode (to the left of hashed line 501). Alternatively the non-secure domain or world 
and the secure user mode may be allowed to be monitored (left of 501 and the portion 
right of 501 that lies below 502). In a further embodiment the non-secure world and 
certain applications running in the secure user domain may be allowed, in this case 
further segmentation by hashed lines 503 occurs. Such divisions help prevent leakage 
of secure data between different users who may be running the different applications. 
In some controlled cases monitoring of the entire system may be allowed. According 
to the granularity required the following parts of the core need to have their access 
controlled during monitoring functions. 

There are four registers that can be set on a Debug event; the instruction Fault 
Status Register (IFSR), Data Fault Status Register (DFSR), Fault Address Register 
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(FAR), and Instruction Fault Address Register (IFAR). These registers should be 
flushed in some embodiments when going from secure world to non-secure world to 
avoid any leak of data. 

5 PC sample register: The Debug TAP can access the PC through scan chain 7. 

When debugging in secure world, that value may be masked depending on the debug 
granularity chosen in secure world. It is important that non-secure world, or non- 
secure world plus secure user applications cannot get any value of the PC while the 
core is running in the secure world. 

10 

TLB entries: Using CP15 it is possible to read micro TLB entries and read and 
write main TLB entries. We can also control main TLB and micro TLB loading and 
matching. This kind of operation must be strictly controlled, particularly if secure 
thread-aware debug requires assistance of the MMU/MPU. 

15 

Performance Monitor Control register: The performance control register gives 
information on the cache misses, micro TLB misses, external memory requests, 
branch instruction executed, etc. Non-secure world should not have access to this 
data, even in Debug State. The counters should be operable in secure world even if 
20 debug is disabled in secure world. 

Debugging in cache system: Debugging must be non-intrusive in a cached 
system. It is important is to keep coherency between cache and external memory. 
The Cache can be invalidated using CP 15, or the cache can be forced to be write- 
25 through in all regions. In any case, allowing the modification of cache behaviour in 
debug can be a security weakness and should be controlled. 

Endianness: Non-secure world or secure user applications that can access to 
debug should not be allowed to change endianness. Changing the endianness could 
30 cause the secure kernel to malfunction. Endianness access is prohibited in debug, 
according to the granularity. 
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Access of the monitoring functions to portions of the core can be controlled at 
initiation of the monitoring function. Debug and trace are initialised in a variety of 
ways. Embodiments of the present technique control the access of the monitoring 
function to certain secure portions of the core by only allowing initialisation under 
5 certain conditions. 

Embodiments of the present technique seek to restrict entry into monitoring 
functions with the following granularity: 

By controlling seperately intrusive and observable (trace) debug; 
10 By allowing debug entry in secure user mode only or in the whole secure 

world; 

By allowing debug in secure user mode only and moreover taking account of 
the thread ID (application running). 

15 In order to control the initiation of a monitoring function it is important to be 

aware of how the functions can be initiated. Figure 34 shows a table illustrating the 
possible ways of initiating a monitoring function, the type of monitoring function that 
is initiated and the way that such an initiation instruction can be programmed. 

20 Generally, these monitoring instructions can be entered via software or via 

hardware, i.e. via the JTAG controller. In order to control the initiation of monitoring 
functions, control values are used. These comprise enable bits which are condition 
dependent and thus, if a particular condition is present, monitoring is only allowed to 
start if the enable bit is set. These bits are stored on a secure register CP 14 (debug and 

25 status control register, DSCR), which is located in ICE 530 (see Figure 41). 

In a preferred embodiment there are four bits that enable/disable intrusive and 
observable debug, these comprise a secure debug enable bit, a secure trace enable bit, 
a secure user-mode enable bit and a secure thread aware enable bit. These control 
30 values serve to provide a degree of controllable granularity for the monitoring 
function and as such can help stop leakage of data from a particular domain. Figure 
35 provides a summary of these bits and how they can be accessed. 
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These control bits are stored in a register in the secure domain and access to 
this register is limited to three possibilities. Software access is provided via ARM 
coprocessor MRG/MCR instructions and these are only allowed from the secure 
5 supervisor mode. Alternatively, software access can be provided from any other mode 
with the use of an authentication code. A further alternative relates more to hardware 
access and involves the instructions being written via an input port on the JTAG. In 
addition to being used to input control values relating to the availability of monitoring 
functions, this input port can be used to input control values relating to other functions 
1 0 of the processor. 

Further details relating to the scan chain and JTAG are given below. 

Register logic cell 

15 

Every integrated circuit (IC) consists of two kind of logic: 
H Combinatory logic cells; like AND, OR, INV gates. Such gates or combination of 
such gates is used to calculate Boolean expressions according to one or several 
input signals. 

20 ■ Register logic cells; like LATCH, FLIP-FLOP. Such cells are used to memorize 
any signal value. Figure 36 shows a positive-edge triggered FLIP-FLOP view: 

When positive-edge event occurs on the clock signal (CK), the output (Q) received 
the value of the input (D); otherwise the output (Q) keeps its value in memory. 

25 

Scan chain cell 



30 



For test or debug purpose, it is required to bypass functional access of register 
logic cells and to have access directly to the contents of the register logic cells. Thus 
register cells are integrated in a scan chain cell as shown in Figure 37. 
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In functional mode, SE (Scan Enable) is clear and the register cell works as a 
single register cell. In test or debug mode, SE is set and input data can come from SI 
input (Scan In) instead of D input. 

Scan chain 

All scan chain cells are chained in scan chain as shown in figure 38. 

In functional mode, SE is clear and all register cells can be accessed normally 
and interact with other logic of the circuit. In Test or Debug mode, SE is set and all 
registers are chained between each other in a scan chain. Data can come from the first 
scan chain cell and can be shifted through any other scan chain cell, at the cadence of 
each clock cycle. Data can be shifted out also to see the contents of the registers. 

TAP controller 

A debug TAP controller is used to handle several scan chains. The TAP controller 
can select a particular scan chain: it connects "Scan In" and "Scan Out" signals to that 
particular scan-chain. Then data can be scanned into the chain,, shifted, or scanned out. 
The TAP controller is controlled externally by a JTAG port interface. Figure 39 
schematically illustrates a TAP controller 

JTAG Selective Disable Scan Chain Cell 

For security reasons, some registers might not be accessible by scan chain, even in 
debug or test mode. A new input called JADI (JTAG Access Disable) can allow 
removal dynamically or statically of a scan chain cell from a whole scan chain, 
without modifying the scan chain structure in the integrated circuit. Figures 40A and 
B schematically show this input. 
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If JADI is inactive (JADI = 0), whether in functional or test or debug mode, the 
scan chain works as usual. If JADI is active (JADI = 1), and if we are in test or debug 
mode, some scan chain cells (chosen by designer), may be "removed" from the scan 
chain structure. In order to keep the same number of scan-chain cell, the JTAG 
Selective Disable Scan Chain Cell use a bypass register. Note that Scan Out (SO) and 
scan chain cell output (Q) are now different. 

Figure 41 schematically shows the processor including parts of the JTAG. In 
normal operation instruction memory 550 communicates with the core and can under 
certain circumstances also communicate with register CP 14 and reset the control 
values. This is generally only allowable from secure supervisor mode. 

When debug is initiated instructions are input via debug TAP 580 and it is 
these that control the core. The core in debug runs in a step by step mode. Debug 
TAP has access to CP 14 via the core (in dependence upon an access control signal 
input on the JSDAEN pin shown as JADI pin, JTAG ACCESS DISABLE INPUT in 
Figure 40) and the control values can also be reset in this way. 

Access to the CP 14 register via debug TAP 580 is controlled by an access 
control signal JSDAEN. This is arranged so that in order for access and in particular 
write access to be allowed JSDAEN must be set high. During board stage when the 
whole processor is being verified, JSDAEN is set high and debug is enabled on the 
whole system. Once the system has been checked, the JSDAEN pin can be tied to 
ground, this means that access to the control values that enable debug in secure mode 
is now not available via Debug TAP 580. Generally processors in production mode 
have JSDAEN tied to ground. Access to the control values is thus, only available via 
the software route via instruction memory 550. Access via this route is limited to 
secure supervisor mode or to another mode provided an authentication code is given 
(see Figure 42). 
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It should be noted that by default debug (intrusive and observable - trace) are 
only available in non-secure world. To enable them to be available in secure world 
the control value enable bits need to be set. 

5 The advantages of this are that debug can always be initiated by users to run in 

non-secure world. Thus, although access to secure world is not generally available to 
users in debug this may not be a problem in many cases because access to this world 
is limited and secure world has been fully verified at board stage prior to being made 
available. It is therefore foreseen that in many cases debugging of the secure world 
10 will not be necessary. A secure supervisor can still initiate debug via the software 
route of writing CP 14 if necessary. 

Figure 42 schematically shows the control of debug initialisation. In this 
figure a portion of the core 600 comprises a storage element 601 (which may be a 
15 CP 15 register as previously discussed) in which is stored a secure status bit S 
indicative of whether the system is in secure world or not. Core 600 also comprises a 
register 602 comprising bits indicative of the mode that the processor is running in, 
for example user mode, and a register 603 providing a context identifier that identifies 
the application or thread that is currently running on the core. 

20 

When a breakpoint is reached comparator 610, which compares a breakpoint 
stored on register 61 lwith the address of the core stored in register 612, sends a signal 
to control logic 620. Control logic 620 looks at the secure state S, the mode 602 and 
the thread (context identifier) 603 and compares it with the control values and 

25 condition indicators stored on register CP14. If the system is not operating in secure 
world, then a "enter debug" signal will be output at 630. If however, the system is 
operating in secure world, the control logic 620 will look at the mode 602, and if it is 
in user mode will check to see if user mode enable and debug enable bits are set. If 
they are then debug will be initialised provided that a thread aware bit has not been 

30 initialised. The above illustrates the hierarchical nature of the control values. 
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The thread aware portion of the monitoring control is also shown 
schematically in Figure 42 along with how the control value stored in register CP 14 
can only be changed from secure supervisor mode (in this embodiment the processor 
is in production stage and JSDAEN is tied to ground). From a secure user mode, 
secure supervisor mode can be entered using an authentication code and then the 
control value can be set in CP 1 4. 

Control logic 620 outputs an "enter debug" signal when address comparator 
610 indicates that a breakpoint has been reached provided thread comparator 640 
shows that debug is allowable for that thread. This assumes that the thread aware 
initialisation bit is set in CP 14. If the thread aware initialisation bit is set following a 
breakpoint, debug or trace can only be entered if address and context identifiers match 
those indicated in the breakpoint and in the allowable thread indicator. Following 
initiation of a monitoring function, the capture of diagnostic data will only continue 
15 while the context identifier is detected by comparator 640 as an allowed thread. When 
a context identifier shows that the application running is not an allowed one, then the 
capture of diagnostic data is suppressed. 
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It should be noted that in the preferred embodiment, there is some hierarchy within 
the granularity. In effect the secure debug or trace enable bit is at the top, followed by 
the secure user-mode enable bit and lastly comes the secure thread aware enable bit. 
This is illustrated in Figures 43 A and 43B (see below). 

The control values held in the "Debug and Status Control" register (CP 14) control 
25 secure debug granularity according to the domain, the mode and the executing thread. 
It is on top of secure supervisor mode. Once the "Debug and Status Control" register 
CP 14 is configured, it's up to secure supervisor mode to program the corresponding 
breakpoints, watchpoints, etc to make the core enter Debug State. 



Figure 43 A shows a summary of the secure debug granularity for intrusive debug . 
Default values at reset are represented in grey colour. 
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It is the same for debug granularity concerning observable debug . Figure 43 B 
shows a summary of secure debug granularity in this case, here default values at reset 
are also represented in grey colour. 

5 Note that Secure user-mode debug enable bit and Secure thread-aware debug 

enable bit are commonly used for intrusive and observable debug. 

A thread aware initialisation bit is stored in register CP 14 and indicates if 
granularity by application is required. If the thread aware bit has been initialised, the 

10 control logic will further check that the application identifier or thread 603 is one 
indicated in the thread aware control value, if it is, then debug will be initialised. If 
either of the user mode or debug enable bits are not set or the thread aware bit is set 
and the application running is not one indicated in the thread aware control value, then 
the breakpoint will be ignored and the core will continue doing what it was doing and 

1 5 debug will not be initialised. 



In addition to controlling initialisation of monitoring functions, the capture of 
diagnostic data during a monitor function can also be controlled in a similar way. In 
order to do this the core must continue to consider both the control values, i.e. the 
20 enable bits stored in register CP 14 and the conditions to which they relate during 
operation of the monitoring function. 



Figure 44 shows schematically granularity of a monitoring function while it is 
running. In this case region A relates to a region in which it is permissible to capture 
25 diagnostic data and region B relates to region in which control values stored in CP 14 
indicate that it is not possible to capture diagnostic data. 



Thus, when debug is running and a program is operating in region A, 
diagnostic data is output in a step-by-step fashion during debug. When operation 
30 switches to Region B, where the capture of diagnostic data is not allowed, debug no 
longer proceeds in a step by step fashion, rather it proceeds atomically and no data is 
captured. This continues until operation of the program re-enters region A whereupon 
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the capture of diagnostic data starts again and debug continues running in a step-by- 
step fashion. 

In the above embodiment, if secure domain is not enabled, a SMI instruction is 
5 always seen as an atomic event and the capture of diagnostic data is suppressed. 

Furthermore, if the thread aware initialisation bit is set then granularity of the 
monitoring function during operation with respect to application also occurs. 

10 

With regard to observable debug or trace, this is done by ETM and is entirely 
independent of debug. When trace is enabled ETM works as usual and when it is 
disabled, ETM hides trace in the secure world, or part of the secure world depending 
on the granularity chosen. One way to avoid ETM capturing and tracing diagnostic 
15 data in the secure domain when this is not enabled is to stall ETM when the S-bit is 
high. This can be done by combining the S-bit with the ETMPWRDOWN signal, so 
that the ETM values are held at their last values when the core enters secure world. 
The ETM should thus trace a SMI instruction and then be stalled until the core returns 
to non-secure world. Thus, the ETM would only see non-secure activity. 

20 

A summary of some of the different monitoring functions and their granularity 
is given below. 

Intrusive debug at board stage 

25 At board stage when the JSDAEN pin is not tied, there is the ability to enable 

debug everywhere before starting any boot session. Similarly, if we are in secure 
supervisor mode we have similar rights. 
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If we initialise debug in halt debug mode all registers are accessible (non-secure 
and secure register banks) and the whole memory can be dumped, except the bits 
dedicated to control debug. 
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Debug halt mode can be entered from whatever mode and from whatever domain. 
Breakpoints and watchpoints can be set in secure or in non-secure memory. In debug 
state, it is possible to enter secure world by simply changing the S bit via an MCR 
instruction. 

As debug mode can be entered when secure exceptions occur, the vector trap 
register is extended with new bits which are; 
SMI vector trapping enable 
Secure data abort vector trapping enable 
Secure prefetch abort vector trapping enable 
Secure undefined vector trapping enable. 

In monitor debug mode, if we allow debug everywhere, even when an SMI is 
called in non-secure world, it is possible to enter secure world in step-by-step debug. 
When a breakpoint occurs in secure domain, the secure abort handler is operable to 
dump secure register bank and secure memory. 

The two abort handlers in secure and in non-secure world give their information to 
the debugger application so that debugger window (on the associated debug 
controlling PC) can show the register state in both secure and non-secure worlds. 

Figure 45A shows what happens when the core is configured in monitor debug 
mode and debug is enabled in secure world. Figure 45B shows what happens when 
the core is configured in monitor debug mode and the debug is disabled in secure 
world. This later process will be described below. 

Intrusive debug at production stage 

In production stage when JSDAEN is tied and debug is restricted to non-secure 
world, unless the secure supervisor determines otherwise, then the table shown in 
Figure 45 B shows what happens. In this case SMI should always be considered as an 
atomic instruction, so that secure functions are always finished before entering debug 
state. 
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Entering debug halt mode is subject to the following restrictions: 

External debug request or internal debug request is taken into account in non- 
5 secure world only. If EDBGRQ (external debug request) is asserted while in secure 
world, the core enters debug halt mode once secure function is terminated and the core 
is returned in non-secure world. 

Programming a breakpoint or watchpoint on secure memory has no effect and 
10 the core is not stopped when the programmed address matches. 

Vector Trap Register (details of this are given below) concerns non-secure 
exceptions only. All extended trapping enable bits explained before have no effect. 

1 5 Once in halt debug mode the following restrictions apply: 

S bit cannot be changed to force secure world entry, unless secure debug is 
enabled. 

Mode bits can not be changed if debug is permitted in secure supervisor mode 

only. 

20 Dedicated bits that control secure debug cannot be changed. 

If a SMI is loaded and executed (with system speed access), the core re-enters 
debug state only when secure function is completely executed. 

25 In monitor debug mode because monitoring cannot occur in secure world, the 
secure abort handler does not need to support a debug monitor programme. In non 
secure world, step-by-step is possible but whenever an SMI is executed secure 
function is executed entirely in other words an XWSI only "step-over" is allowed 
while "step-in" and "step-over" are possible on all other instructions. XWSI is thus 

30 considered an atomic instruction. 

Once secure debug is disabled, we have the following restrictions: 
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Before entering monitor mode: 

Breakpoints and watchpoints are only taken into account in non-secure world. If bit 
S is set, breakpoints/watchpoints are bypassed. Note that watchpoints units are also 
accessible with MCR/MRC (CP 14) which is not a security issue as 
breakpoint/watchpoint has no effect in secure memory. 

BKPT are normally used to replace the instruction on which breakpoint is set. This 
supposes to overwrite this instruction in memory by BKPT instruction, which will be 
possible only in non-secure mode. 

Vector Trap Register concerns non-secure exceptions only. All extended trapping 
enable bits explained before have no effect. Data abort and Pre-fetch abort enable bits 
should be disabled to avoid the processor being forced in to an unrecoverable state. 

Via JTAG, we have the same restrictions as for halt mode (S bit cannot be 
modified, etc) 

Once in monitor mode (non-secure abort mode) 

The non-secure abort handler can dump non-secure world and has no visibility on 
secure banked registers as well as secure memory. 

Executes secure functions with atomic SMI instruction 
S bit cannot be changed to force secure world entry. 

Mode bits can not be changed if debug is permitted in secure supervisor mode only. 

Note that if an external debug request (EDBGRQ) occurs, 

In non-secure world, the core terminates the current instruction and enters then 

immediately debug state (in halt mode). 

In secure world, the core terminates the current function and enters the Debug State 

when it has returned in non-secure world. 
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The new debug requirements imply some modifications in core hardware. The S 
bit must be carefully controlled, and the secure bit must not be inserted in a scan chain 
for security reason. 

In summary, in debug, mode bits can be altered only if debug is enabled in secure 
supervisor mode. It will prevent anybody that has access to debug in the secure 
domain to have access to all secure world by altering the system (modifying TBL 
entries, etc). In that way each thread can debug its own code, and only its own code. 
The secure kernel must be kept safe. Thus when entering debug while the core is 
running in non-secure world, mode bits can only be altered as before. 

Embodiments of the technique use a new vector trap register. If one of the bits in 
this register is set high and the corresponding vector triggers, the processor enters 
debug state as if a breakpoint has been set on an instruction fetch from the relevant 
exception vector. The behaviour of these bits may be different according to the value 
of 'Debug in Secure world Enable 1 bit in debug control register. 

The new vector trap register comprises the following bits: D_s_abort, P_s_abort, 
S_undef, SMI, FIQ, IRQ, Unaligned, D_abort, P_abort, S WI and Undef. 

• Dsabort bit: should only be set when debug is enabled in secure world and when 
debug is configured in halt debug mode. In monitor debug mode, this bit should 
never bit set. If debug in secure world is disabled, this bit has no effect whatever 
its value. 

• P_s_abort bit: same as D_s_abort bit. 

• S_undef bit: should only be set when debug is enable in secure world. If debug in 
secure world is disabled, this bit has no effect whatever its value is. 
SMI bit: should only be set when debug is enabled in secure world. If debug in 
secure world is disabled, this bit has no effect whatever its value is. 
FIQ, IRQ, D_abort, P_abort, SWI, undef bits: correspond to non- secure 
exceptions, so they are valid even if debug in secure world is disabled. Note that 
D_abort and P_abort should not be asserted high in monitor mode. 
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• Reset bit: as we enter secure world when reset occurs, this bit is valid only when 
debug in secure world is enabled, otherwise it has no effect. 

Although a particular embodiment of the invention has been described herein, 
5 it will be apparent that the invention is not limited thereto, and that many 
modifications and additions may be made within the scope of the invention. For 
example, various combinations of the features of the following dependent could be 
made with the features of the independent claims without departing from the scope of 
the present invention. 
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CLAIMS 

1 . A data processing apparatus, comprising: 

a processor operable in a plurality of modes and either a secure domain or a non- 
secure domain, including at least one non-secure mode being a mode in the non-secure 
domain and at least one secure mode being a mode in the secure domain, in said at least 
one non-secure mode the processor being operable under the control of a non-secure 
operating system and in said at least one secure mode the processor being operable 
under the control of a secure operating system; 

a memory operable to store data required by the processor and comprising secure 
memory for storing secure data and non-secure memory for storing non-secure data, the 
processor being operable to issue a memory access request when access to an item of 
data in the memory is required; 

a memory management unit operable, upon receipt of the memory access request 
from the processor, to perform one or more predetermined access control functions to 
control issuance of the memory access request to the memory; and 

partition checking logic managed by the secure operating system, and operable 
whenever the memory access request is issued by the processor when operating in said 
at least one non-secure mode to detect if the memory access request is seeking to access 
the secure memory, and upon such detection to prevent the access specified by that 
memory access request. 

2. A data processing apparatus as claimed in Claim 1, wherein when the processor 
is operating in the at least one non-secure mode, the memory access request specifies a 
virtual address, the memory management unit is controlled by the non-secure operating 
system and one of said predetermined access control functions performed by the 
memory management unit comprises conversion of the virtual address to a physical 
address, the partition checking logic being operable to prevent the access specified by 
that memory access request if the physical address to be generated by the memory 
management unit is within the secure memory. 
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3. A data processing apparatus as claimed in Claim 1 or Claim 2, wherein when the 
processor is operating in one of the at least one secure modes, the memory access 
request specifies a virtual address, the memory management unit is controlled by the 
secure operating system and one of said predetermined access control functions 
performed by the memory management unit comprises conversion of the virtual address 
to a physical address, the partition checking logic not being used in the at least one 
secure mode. 

4. A data processing apparatus as claimed in Claim 3, wherein for all modes of 
operation of the processor, the memory access request specifies a virtual address, the 
partition checking logic being provided within the memory management unit, and being 
operable whenever the processor is operating in said at least one non-secure mode. 

5. A data processing apparatus as claimed in Claim 2 or Claim 3, further 
comprising a memory protection unit within which the partition checking logic is 
provided, the memory protection unit being managed by the secure operating system, 
wherein when the processor is operating in a particular secure mode, the memory access 
request specifies a physical address for a memory location, the memory management 
unit is not used, and the memory protection unit is operable to perform at least memory 
access permission processing to verify whether the memory location specified by the 
physical address is accessible in said particular secure mode. 

6. A data processing apparatus as claimed in any preceding claim, wherein the 
memory includes at least one table containing for each of a number of memory regions 
an associated descriptor, the memory management unit comprising an internal storage 
unit for storing access control information derived from the descriptors and used by the 
memory management unit to perform the predetermined access control functions for the 
memory access request, the partition checking logic being operable, when the processor 
is operating in said at least one non-secure mode, to prevent the internal storage unit 
from storing access control information that would allow access to said secure memory. 
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7. A data processing apparatus as claimed in Claim 6, wherein the memory access 
request specifies a virtual address, and one of said predetermined access control 
functions comprises conversion of the virtual address to a physical address, each 
descriptor containing at least a virtual address portion and a corresponding physical 

5 address portion for the corresponding memory region, the partition checking logic being 
operable, when the processor is operating in said at least one non-secure mode, to 
prevent the internal storage unit from storing as access control information the physical 
address portion if the physical address that would then be produced for the virtual 
address is within the secure memory. 

10 

8. A data processing apparatus as claimed in Claim 7, wherein the internal storage 
unit is a translation lookaside buffer (TLB) operable to store for a number of virtual 
address portions the corresponding physical address portions obtained from 
corresponding descriptors retrieved from the at least one table. 

15 

9. A data processing apparatus as claimed in claim 8, wherein the TLB is a micro- 
TLB, and the internal storage unit further comprises a main TLB for storing descriptors 
retrieved by the memory management unit from the at least one table, access control 
information being transferred from the main TLB to the micro-TLB prior to use of that 

20 access control information by the memory management unit to perform the 
predetermined access control functions for the memory access request, the partition 
checking logic being operable, when the processor is operating in said at least one non- 
secure mode, to prevent the transfer of any access control information from the main 
TLB to the micro-TLB that would allow access to said secure memory. 

25 

10. A data processing apparatus as claimed in any of claims 7 to 9, wherein the at 
least one table comprises a non-secure table for use when the processor is operating in 
said at least one non-secure mode and containing descriptors generated by the non- 
secure operating system, in the event that a descriptor within that non-secure table is 

30 associated with a memory region that at least partially incorporates a part of the secure 
memory, the partition checking logic being operable, when the processor is operating in 
non-secure mode, to prevent the internal storage unit from storing as access control 
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information the physical address portion specified by that descriptor if the physical 
address that would then be produced for the virtual address is within the secure memory. 



11. A data processing apparatus as claimed in Claim 10 when dependent on Claim 
9, wherein the at least one table further comprises a secure table within the secure 
memory that contains descriptors generated by the secure operating system, the main 
TLB comprising a flag associated with each descriptor stored within the main TLB to 
identify whether that descriptor is from said non-secure table or said secure table. 

12. A data processing apparatus as claimed in Claim 11, wherein the micro-TLB is 
flushed whenever the mode of operation of the processor changes between a secure 
mode and a non-secure mode, in the secure mode access control information only being 
transferred to the micro-TLB from a descriptor in the main TLB that said associated flag 
indicates is from the secure table, and in the non-secure mode access control information 
only being transferred to the micro-TLB from a descriptor in the main TLB that said 
associated flag indicates is from the non-secure table. 

13. A data processing apparatus as claimed in any preceding claim when dependent 
on Claim 6, wherein said at least one table comprises at least one page table. 

14. A data processing apparatus as claimed in any preceding claim, wherein the 
memory is coupled to a device bus via which a device other than the processor may seek 
access to the memory, the apparatus further comprising additional partition checking 
logic coupled to the device bus and operable when said device issues a memory access 
request to said secure memory to only allow access to said secure memory if that device 
is authorised to access said secure memory. 

15. A data processing apparatus as claimed in Claim 14, wherein the additional 
partition checking logic has regard to a current mode of operation of said device. 
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16. A data processing apparatus as claimed in Claim 15, wherein the memory access 
request issued by the device includes a domain signal identifying whether the device is 
operating in said at least one secure mode or said at least one non-secure mode. 

17. A data processing apparatus as claimed in Claim 16, wherein the device has a 
predetermined pin for outputting the domain signal onto the device bus. 

18. A data processing apparatus as claimed in any preceding claim, wherein the 
processor is coupled to a system bus, and a part of the memory comprises a tightly 
coupled memory connected to the system bus, the physical address range for the tightly 
coupled memory being defined in a control register, and a control flag being settable by 
the processor when operating in a privileged secure mode to indicate whether the tightly 
coupled memory is controllable by the processor only when executing in a privileged 
secure mode or is controllable by the processor when executing in the at least one non- 
secure mode. 

19. A data processing apparatus as claimed in Claim 18, wherein if the tightly 
coupled memory is controllable by the processor when executing in the at least one non- 
secure mode, secure data is prevented from being stored in the tightly coupled memory. 

20. A method of controlling access to a memory in a data processing apparatus, 
the data processing apparatus comprising a processor operable in a plurality of modes 
and either a secure domain or a non-secure domain, including at least one non-secure 
mode being a mode in the non-secure domain and at least one secure mode being a 
mode in the secure domain, in said at least one non-secure mode the processor being 
operable under the control of a non-secure operating system and in said at least one 
secure mode the processor being operable under the control of a secure operating 
system, the memory being operable to store data required by the processor and 
comprising secure memory for storing secure data and non-secure memory for storing 
non-secure data, the method comprising the steps of: 

(i) issuing from the processor a memory access request when access to an item of 
data in the memory is required; 
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(ii) performing one or more predetermined access control functions to control 
issuance of the memory access request to the memory: 

(iii) whenever the memory access request is issued by the processor when operating 
in said at least one non-secure mode, employing partition checking logic managed by the 
secure operating system to detect if the memory access request is seeking to access the 
secure memory; and 

(iv) upon such detection, preventing the access specified by that memory access 
request. 



21. A method as claimed in Claim 20, wherein when the processor is operating in 
the at least one non-secure mode, the memory access request issued at said step (i) 
specifies a virtual address, said step (ii) is controlled by the non-secure operating system 
and one of said predetermined access control functions performed at said step (ii) 
comprises conversion of the virtual address to a physical address, the partition checking 
15 logic preventing at said step (iv) the access specified by that memory access request if 
the physical address generated by the memory management unit is within the secure 
memory. 



22. A method as claimed in Claim 20 or Claim 21, wherein when the processor is 
operating in one of the at least one secure modes, the memory access request issued at 
said step (i) specifies a virtual address, said step (ii) is controlled by the secure operating 
system and one of said predetermined access control functions performed at said step (ii) 
comprises conversion of the virtual address to a physical address, the partition checking 
logic not being used in the at least one secure mode. 



23. A method as claimed in Claim 22, wherein for all modes of operation of the 
processor, the memory access request issued at said step (i) specifies a virtual address, 
the partition checking logic being provided within a memory management unit used to 
perform said step (ii), and being operable whenever the processor is operating in said at 
30 least one non-secure mode. 
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24. A method as claimed in Claim 21 or Claim 22, wherein the data processing 
apparatus further comprises a memory protection unit within which the partition 
checking logic is provided, the memory protection unit being managed by the secure 
operating system, wherein when the processor is operating in a particular secure mode, 
the memory access request issued at said step (i) specifies a physical address for a 
memory location, said step (ii) is not performed, and the memory protection unit 
performs at least memory access permission processing to verify whether the memory 
location specified by the physical address is accessible in said particular secure mode. 

25. A method as claimed in any of claims 20 to 24, wherein the memory comprises 
at least one table containing for each of a number of memory regions an associated 
descriptor, the method comprising the steps of: 

providing within a memory management unit used to perform said step (ii) an 
internal storage unit for storing access control information derived from the descriptors 
and used by the memory management unit to perform the predetermined access control 
functions for the memory access request; and 

when the processor is operating in said at least one non-secure mode, employing 
the partition checking logic to prevent the internal storage unit from storing access 
control information that would allow access to said secure memory. 

26. A method as claimed in Claim 25, wherein the memory access request issued at 
said step (i) specifies a virtual address, and one of said predetermined access control 
functions performed at said step (ii) comprises conversion of the virtual address to a 
physical address, each descriptor containing at least a virtual address portion and a 
corresponding physical address portion for the corresponding memory region, the 
method comprising the step of: 

when the processor is operating in said at least one non-secure mode, employing 
the partition checking logic to prevent the internal storage unit from storing as access 
control information the physical address portion if the physical address that would then 
be produced for the virtual address is within the secure memory. 
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27. A method as claimed in Claim 26, wherein the internal storage unit is a 
translation lookaside buffer (TLB) operable to store for a number of virtual address 
portions the corresponding physical address portions obtained from corresponding 
descriptors retrieved from the at least one table. 

28. A method as claimed in claim 27, wherein the TLB is a micro-TLB, and the 
internal storage unit further comprises a main TLB for storing descriptors retrieved by 
the memory management unit from the at least one table, the method comprising the 
step of: 

transferring access control information from the main TLB to the micro-TLB 
prior to use of that access control information at said step (ii) to perform the 
predetermined access control functions for the memory access request; and 

when the processor is operating in said at least one non-secure mode, employing 
the partition checking logic to prevent the transfer of any access control information 
from the main TLB to the micro-TLB that would allow access to said secure memory. 

29. A method as claimed in any of claims 26 to 28, wherein the at least one table 
comprises a non-secure table for use when the processor is operating in said at least one 
non-secure mode and containing descriptors generated by the non-secure operating 
system, in the event that a descriptor within that non-secure table is associated with a 
memory region that at least partially incorporates a part of the secure memory, the 
method comprising the step of: 

when the processor is operating in non-secure mode, employing the partition 
checking logic to prevent the internal storage unit from storing as access control 
information the physical address portion specified by that descriptor if the physical 
address that would then be produced for the virtual address is within the secure memory. 

30. A method as claimed in Claim 29 when dependent on Claim 28, wherein the at 
least one table further comprises a secure table within the secure memory that contains 
descriptors generated by the secure operating system, the main TLB comprising a flag 
associated with each descriptor stored within the main TLB, and the method comprising 
the step of: 
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when a descriptor is stored in the main TLB, setting the associated flag to 
identify whether that descriptor is from said non-secure table or said secure table. 



31. A method as claimed in Claim 30. further comprising the step of: 

flushing the micro-TLB whenever the mode of operation of the processor 
changes between a secure mode and a non-secure mode; 

in the secure mode, only transferring access control information to the micro- 
TLB from a descriptor in the main TLB that said associated flag indicates is from the 
secure table; and 

in the non-secure mode, only transferring access control information to the 
micro-TLB from a descriptor in the main TLB that said associated flag indicates is from 
the non-secure table. 

32. A method as claimed in any of claims 20 to 31 when dependent on Claim 25, 
wherein said at least one table comprises at least one page table. 

33. A method as claimed in any of claims 20 to 32, wherein the memory is coupled 
to a device bus via which a device other than the processor may seek access to the 
memory, the apparatus further comprising additional partition checking logic coupled to 
the device bus and the method comprising the step of: 

when said device issues a memory access request to said secure memory, 
employing the additional partition checking logic to only allow said device access to 
said secure memory if that device is authorised to access said secure memory. 

34. A method as claimed in Claim 33, wherein the additional partition checking 
logic has regard to a current mode of operation of said device. 

35. A method as claimed in Claim 34, wherein the memory access request issued by 
the device includes a domain signal identifying whether the device is operating in said at 
least one secure mode or said at least one non-secure mode. 
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36. A method as claimed in Claim 35, wherein the device has a predetermined pin 
for outputting the domain signal onto the device bus. 

37. A method as claimed in any of claims 20 to 36, wherein the processor is coupled 
5 to a system bus, and a part of the memory comprises a tightly coupled memory 

connected to the system bus, the method comprising the steps of: 

defining in a control register the physical address range for the tightly coupled 
memory; and 

setting, by the processor when operating in a privileged secure mode, a control 
1 0 flag to indicate whether the tightly coupled memory is controllable by the processor only 
when executing in a privileged secure mode or is controllable by the processor when 
executing in the at least one non-secure mode. 

38. A method as claimed in Claim 37, wherein if the tightly coupled memory is 
1 5 controllable by the processor when executing in the at least one non-secure mode, secure 

data is prevented from being stored in the tightly coupled memory. 

39. A data processing apparatus, substantially as hereinbefore described with 
reference to Figures 21 to 32. 

20 

40. A method of controlling access to a memory in a data processing apparatus, 
substantially as hereinbefore described with reference to Figures 21 to 32. 
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ABSTRACT 

APPARATUS AND METHOD FOR CONTROLLING 
ACCESS TO A MEMORY 

5 

The present invention provides a data processing apparatus and method for 
controlling access to a memory within the data processing apparatus. The data 
processing apparatus comprises a processor which is operable in a plurality of modes 
and either a secure domain or a non-secure domain, including at least one non-secure 
10 mode being a mode in the non-secure domain, and at least one secure mode being a 
mode in the secure domain. In a non-secure mode, the processor is operable under the 
control of a non-secure operating system, and in a secure mode the processor is 
operable under the control of a secure operating system. A memory is provided for 
storing data required by the processor, and consists of secure memory for storing 
15 secure data and non-secure memory for storing non-secure data. When access to an 
item of data in the memory is required, the processor is operable to issue a memory 
access request, and a memory management unit within the data processing apparatus 
is then used to perform one or more predetermined access control functions to control 
issuance of that memory access request to the memory. In accordance with the 
20 present invention, partition checking logic is also provided which is managed by the 
secure operating system, and is operable whenever the memory access request is 
issued by the processor when operating in a non-secure mode to detect if the memory 
access request is seeking to access the secure memory. If such an activity is detected, 
the partition checking logic is arranged to prevent the access specified by that memory 
25 access request. This approach has been found to significantly improve the security of 
secure data stored within the secure memory. 
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L 



3U 



Yes 


access 


Yes 


> — ► 


permission fault 
ABORT 
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No 




memory 
: access 
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/S/3? 



f core generates 
I physical address 



_- _ MPU checks 
-permissions and if 
non ? seciife:.pnysjcai ■. 
' address is to 
non-secure memory 



3^ 



.3SV 



^1 



Yes 



access permission fault 
ABORT 





r 

4t 



the descriptor 
describes a section 
that overlaps 
Secure regions 



/ 

318* 



NS 



270 



-EM 



NS 



NS 



VA 



311+- 



\ 



VA 



If VA corresponds to PA in secure 
memory 

=> partition checker generates an 
ABORT 



If VA corresponds to PA in non- 
secure memory 

=> this region is loaded in uTLB 



Secure memory 
j [ Non-secure memory 
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non-secure pages 
table 



non-secure 
translation 
table base 
address 




secure 
translation 
table base 
address 
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Free memory 
for OS 



Free memory 
for secure 
kernel 



Secure allocated 
memory for 

secure 
application 
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Method of entry 


How to program? 


How to enter? 


Entry mode 


Breakpoint hits 


Debug TAP or 
software (CP14) 


Program breakpoint register and/or 
context-ID register and comparisons 
succeed with Instruction Address and/or 
CP1 5 Context ID ( 2 ). 


Halt/monitor 

0 


Software breakpoint 
instruction 


Put a BKPT instruction into scan 
chain 4 (Instruction Transfer 
Register) through Debug TAP or 

Use BKPT instruction directly in 
the code. 


BKPT instruction must reach execution 
stage. 


Halt/monitor 


Vector trap breakpoint 


Debug TAP 


Program vector trap register and 
address matches. 


Halt/monitor 


Watchpoint hits 


Debug TAP 
or software (CP14) 


Program watchpoint register and/or 
context-ID register and comparisons 
succeed with Instruction Address and/or 
CP15 Context ID ( 2 ). 


Halt/monitor 

D 


Internal debug request 


Debug TAP 


Halt instruction has been scanned in. 


Halt 


External debug request 


Not-applicable j 


EDBGRQ input pin is asserted. 


Halt 



In monitor mode, breakpoints and watchpoints cannot be data-dependent. 

( 2 ): The cores have support for thread-aware breakpoints and watchpointsaACcd^teoioU.^ io enable secure 
debug on some particular threads. 
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Name 


Meaning 


Reset 
" value 


Access 


: Inserted in 
scan chain 
for test 


Monitor 
mode enable 
bit 


0: halt mode 
1: monitor mode 


1 


RAV by programming the ICE by the JTAG (scanl) 
■ RAV by using MRC/MCR instruction (CP 1 4) 


/ yes 


Secure debug 
enable bit 


0: debug in non- 
secure world only. 
1 : debug in secure 
world and non- 
secure world 


0 


In functional mode or debug monitor mode: RAV by 
using MRC/MCR instruction (CP 14) (only in secure 
supervisor mode) 

In Debug halt mode: No access - MCR/MRC 
instructions have any effect. 

(RAV by programming the ICE by the JTAG (scanl) 
if JSDAEN=1 


no 


Secure trace 
enable bit 


0: ETM is enabled 

in non-secure 

world only. 

1: ETM is enabled 

in secure world 

and non-secure 

world 


0 


In functional mode or debug monitor mode: RAV by 
using MRC/MCR instruction (CP 14) (only in secure 
supervisor mode) 

In Debug halt mode: No access - MCR/MRC 
instructions have any effect. 

(RAV by programming the ICE by the JTAG (scanl) 
if JSDAEN=1 


no 


Secure user- 
mode enable 
bit 


0: debug is not 
possible in secure 
user mode 
1: debug is 
possible in secure 
user mode 


1 


In functional mode or debug monitor mode: RAV by 
using MRC/MCR instruction (CP 14) (only in secure 
supervisor mode) 

In Debug halt mode: No access - MCR/MRC 
instructions have any effect. 

(RAV by programming the ICE by the JTAG (scanl) 
if JSDAEN=1 


no 


Secure 
thread-aware 
enable bit 


0: debug is not 
possible for a 
particular thread 
1 : debug is 
possible for a 
particular thread 


0 


In functional mode or debug monitor mode: RAV by 
using MRC/MCR instruction (CP 14) (only in secure 
supervisor mode) 

In Debug halt mode: No access - MCR/MRC 
instructions have any effect. 

(RAV by prograrriming the ICE by the JTAG (scanl) 
if JSDAEN=1 


no 



Figure 3S 
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Function Table 
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CK 


Q[n+1] 


0 




0 


1 
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X 




QW 



Logic Symbol 
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CK _ 




FIGURE 36 
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Function Table 



Logic Symbol 



D 


SI 


SE 


CK 


Q[n+1] 


0 


X 


0 




0 


1 


X 


0 




1 


X 


X 


X 




QM 


X 


0 


1 




0 


X 


1 


1 




1 



SI _l 

D 
SE 

CK 
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Figure 37 
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JTAG 
interface 



TAP 
controller 



Scan In 



Integrated 
Circuit 



rot 



Scan Out 



FIGURE 39 




V. 



Instruction 
Memory 



(1) 



/FT 




CORE 



ICE 



CP14 Debug Status 
& Control Register ' 



7TT 



(2) 



SCAN CHAIN 1 



I 

JSDAEN 



ft 
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JADI 



JTAG 
interface 



TAP 
controller 



Scan In 



Integrated 
Circuit 
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Scan Out 



FIGURE 40A 
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CP 14 bits in Debug and Status Control register 


meaning 


Secure debug enable 
bit 


Secure user-mode 

LLCUUg ClidUIC OIL 


Secure thread-aware 
aeoug enaoie Dit 


0 


X 


X 


nu muudivc ucuug in ciiiixc secure woriQ is possioie. 
Any debug request, breakpoints, watchpoints, and other 
mechanism to enter debug state are ignored in entire 
secure world. 


1 


o 


x 


Debug in entire secure world is possible j 


1 


1 


0 


Debug in secure user-mode only. Any debug request, 
breakpoints, watchpoints, and other mechanism to enter 
debug state are taken into account in user mode only. 
(Breakpoints and watchpoints linked or not to a thread 
ED are taken into account). Access in debug is restricted 
to what secure user can have access to. 


1 


1 


1 


Debug is possible only in some particular threads. In 
that case only thread-aware breakpoints and 
watchpoints linked to a thread ED are taken into account 
to enter debug state. Each thread can moreover debug 
its own code, and only its own code. 



Figure j+BA 



CP 14 bits in Debug and Status Control register 


meaning 


Secure trace enable 
bit 


Secure user-mode 
debug enable bit 


Secure thread-aware 
debug enable bit 


0 


X 


X 


No observable debug in entire secure world is possible. 
Trace module (ETM) must not trace internal core 
activity. 


1 


0 


X 


Trace in entire secure world is possible 


1 


1 


0 


Trace is possible when the core is in secure user-mode 
only. 


1 


1 


1 


Trace is possible only when the core is executing some 
particular threads in secure user mode. Particular 
hardware must be dedicated for this, or re-use 
breakpoint register pair: Context ED match must enable 
trace instead of entering debug state. 



Figure 436 




i; . . ■ ■ M 



4 



a : 5 

~ 1 



ft 



39/39 





Entry when in non-secure world 


entry when in secure world 


Breakpoint hits 


Non-secure prefetch abort handler 


secure prefetch abort handler 


Software breakpoint instruction 


Non-secure prefetch abort handler 


secure prefetch abort handler 


Vector trap breakpoint 


Disabled for non-secure data abort 
and non-secure prefetch abort 
interruptions. For other non-secure 
exceptions, prefetch abort. 


Disabled for secure data abort and 
secure prefetch abort exceptions C). 
For other exceptions, secure prefetch 
abort. 


Watchpoint hits 


Non-secure data abort handler 


secure data abort handler 


Internal debug request 


Debug state in halt mode 


debug state in halt mode 


External debug request 


Debug state in halt mode 


debug state in halt mode 


See irtfr^<**x£\6<\ on vector trap register, l 
(2) Note that when external or internal debug request is asserted, the core enters halt mode and not monitor 

Figure 




Entry in non-secure world 


entry in secure world 


Breakpoint hits 


Non-secure prefetch abort handler 


breakpoint ignored 


Software breakpoint instruction 


Non-secure prefetch abort handler 


iratrupfo^ - 


Vector trap breakpoint 


Disabled for non-secure data abort and 
non-secure prefetch abort interruptions. 
For others interruption non-secure prefetch 
abort. 


breakpoint ignored;^ % 

; . , 


Watchpoint hits ] 


Non-secure data abort handler 


watchpoint ignored; 5 , \ 


Internal debug request ] 


Debug state in halt mode 


requestiignored y 


External debug request ] 


Debug state in halt mode 


request ignored ';,.„', 


Debug re-entry from system i 
speed access 


lot'applicable % 


not applicableVv i , . 



(') As substitution of BKPT instruction in secure world from non-secure world is not possible, non-secure abort 
must handle the violation. 



Figure 4 H £ 



